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ABSTRACT 
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Maritime  Forces 


Executive  Summary 

A  key  challenge  in  modem  surface  warfare  is  the  integration  of  many  different 
systems.  These  include  on-board  and  off-board  sensors,  data  fusion  systems,  command 
decision  aids,  conunand  and  control  {O)  systems,  weapons  and  the  platform  itself. 
There  is  currently  a  gap  in  the  capability  to  rigorously  study  these  integration 
requirements  in  a  laboratory  environment.  Additionally,  the  capability  is  lacking  to 
comprehensively  investigate  the  operational  efficacy  of  new  systems  prior  to  then- 
introduction  to  service. 

The  Virtual  Ship  wiU  provide  a  facility  through  which  these  issues  may  be  addressed. 

It  will  exploit  modem  computing  capability,  particularly  distributed  simtdation 
technology,  to  bring  together  simulations  of  ship  systems  in  order  that  warship 
operations  may  be  simulated.  The  Virtual  Ship  wiU  provide  a  human-in-the-loop 
capability  in  that  human  operators  may  interact  in  real  time  with  the  simulations  just 
as  they  would  interact  with  the  real  system. 

The  Virtual  Ship  will  find  application  in  support  of  a  number  of  DSTO  and  ADF 
objectives.  It  will  provide  an  environment  within  which  the  operational  utility  of 
sensors,  signal  processing  techniques,  data  fusion  techniques,  command  decision  aids 
and  weapon  systems  may  be  demonstrated  and  refined.  It  will  enable  the  operational 
perspective  to  be  accounted  for  in  the  laboratory,  prior  to  expensive  sea  trials.  It  also 
provides  a  means  by  which  system  user  requirements  may  be  eHcited  in  a  controUed 
and  cost  effective  manner. 

These  potential  applications  of  the  Virtual  Ship  are  not  limited  to  supporting  the  force 
in  being.  The  significant  advantage  that  a  "virtual"  environment  offers  is  that  of 
integrating  models  of  systems  that  represent  the  latest  technology,  or  represent  future 
technological  prospects.  With  these  models  the  Virtual  Ship  may  be  used  to  assess  the 
operational  utiUty  of  concept  platforms,  or  platforms  proposed  during  an  acquisition. 
The  requirement  for  a  new  platform  may  be  specified  in  terms  of  the  Virtual  Ship.  The 
integration  requirements  associated  with  new  systems  may  also  be  explored  in  the 
virtual  environment.  It  is  in  this  way  that  the  Virtual  Ship  will  support  the  capabiHty 
development  and  acquisition  processes. 

The  Virtual  Ship  will  support  the  force  in  being  through  its  contribution  to  training, 
tactical  development,  mission  rehearsal  and  studies  of  operational  concepts.  In 
addition,  exploiting  the  Virtual  Ship  from  the  earliest  phases  of  the  platform  life  will 
mean  that  these  activities  can  be  performed  prior  to  the  platform  being  manufactured. 
This  offers  the  possibility  that  the  Virtual  Ship  wiU  facilitate  a  new  platform  being 


introduced  into  service  accompanied  by  mature  training  and  operational  doctrine  that 
exploits  the  platform's  unique  capabilities. 

The  Virtual  Ship  wiU  share  a  close  relationship  with  operations  research.  Operations 
research  has  traditionally  been  concerned  with  mathematical  modelling  and 
constructive  simulation.  Measures  of  effectiveness  are  rigorously  computed,  often 
exploiting  statistical  techniques.  The  Virtual  Ship  wiU  complement  this  capability 
through  the  fidelity  it  provides  and  through  its  ability  to  capture  human  performance 
characteristics.  The  concept  that  unifies  them  is  that  of  supporting  military  decision¬ 
making. 

The  Virtual  Ship  will  be  based  upon  the  High  Level  Architecture  (HLA),  which  is  a 
framework  supporting  distributed  simulation.  It  enables  individual  simulation  systems 
to  exchange  data  over  a  network  in  such  a  manner  that  they  may  operate  within  a 
common  virtual  environment.  The  HLA  will  be  customised  to  support  the  integration 
of  simulation  models  m  the  maritime  domain.  The  Virtual  Ship  Architecture  (VSA) 
refers  to  those  components  required  to  simulate  warship  operations,  over  and  above 
the  components  of  the  HLA. 

The  provision  and  collection  of  data  are  essential  processes  associated  with  the  Virtual 
Ship.  Data  must  be  provided  to  characterise  the  simulated  entities,  their  interactions 
and  ihe  environment.  Data  collection  during  simulation  facilitates  analysis  and 
decision  making. 

Participation  of  Industry  in  the  Virtual  Ship  project  is  essential  to  its  success.  Industry 
wiU  be  a  significant  source  of  models,  whether  the  intention  is  to  represent  the  force  in 
being,  or  to  represent  future  platforms  in  the  context  of  capability  development  or 
acqmsition. 

The  initial  phase  in  establishing  a  Virtual  Ship  shall  be  concerned  with  the  technical 
requirements  associated  with  adopting  the  High  Level  Architecture.  As  the  HLA  is 
mastered  attention  will  be  focused  on  development  of  guidelines  for  using  the  Virtual 
Ship.  An  essential  characteristic  of  the  Virtual  Ship  is  its  human-in-the-loop  capability. 
The  gmdelines  for  use  wiU  emphasise  capturing  the  performance  of  trained  operators 
in  a  manner  that  is  credible  in  the  eyes  of  Virtual  Ship  users  and  the  decision  makers 
who  utilise  its  outputs.  The  contribution  of  the  RAN  to  this  process  is  critical. 

The  Virtual  Ship  will  evolve  into  a  dedicated  facility  available  to  support  activities 
across  the  whole  of  the  Defence  Department.  It  will  contribute  significantly  to  research, 
force  development,  acquisition,  training,  mission  rehearsal  and  tactical  development. 
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1.  Introduction 

A  key  challenge  in  modem  surface  warfare  is  the  integration  of  many  different 
systems.  These  include  on-board  and  off-board  sensors,  data  fusion  systems, 
command  decision  aids,  command  and  control  (C2)  systems,  weapons  and  the 
platform  itself.  There  is  currently  a  gap  in  the  capability  to  rigorously  study  these 
integration  requirements  in  a  laboratory  environment.  Additionally,  the  capability  is 
lacking  to  comprehensively  investigate  the  operational  efficacy  of  new  systems  prior 
to  their  introduction  to  service. 

The  Virtual  Ship  will  provide  a  facility  through  which  these  issues  may  be 
addressed.  It  will  exploit  modem  computing  capability,  particularly  distributed 
simulation  technology,  to  bring  together  simulations  of  ship  systems  in  order  that 
warship  operations  may  be  simulated.  The  Virtual  Ship  wiU  provide  a  human-in-the- 
loop  capability  in  that  human  operators  may  interact  with  the  simulations  just  as 
they  would  interact  with  the  real  system.  The  essential  characteristic  in  th^  regard  is 
realism.  It  is  only  through  creation  of  a  highly  realistic  virtual  representation  of  a 
warship  operations  room  that  the  Virtual  Ship  wiU  attain  the  credibility  required  in 
order  that  it  be  used  as  a  basis  for  mihtary  decision  making. 

The  Virtual  Ship  wiU  find  appHcation  in  support  of  a  number  of  DSTO  and  ADF 
objectives.  It  will  provide  an  environment  within  which  the  operational  utiHty  of 
sensors,  signal  processing  techmques,  data  fusion  techniques,  command  decision 
aids  and  weapon  systems  may  be  demonstrated  and  refined.  It  will  enable  the 
operational  perspective  to  be  accotmted  for  in  the  laboratory,  prior  to  expensive  sea 
trials.  It  also  provides  a  means  by  which  system  user  requirements  may  be  elicited  in 
a  controlled  and  cost  effective  manner. 

The  Virtual  Ship  will  provide  an  environment  within  which  integration  issues  may 
be  explored  and  requirements  determined.  Prominent  examples  include  integration 
of  new  tactical  data  sources,  weapon  systems  and  sensors.  Particular  emphasis  will 
be  placed  upon  operator  needs  in  order  that  new  capabilities  are  fully  exploited. 

The  Virtual  Ship  will  also  provide  an  environment  within  which  tactics  and 
operational  concepts  may  be  explored.  It  is  in  this  category  of  applications  that  the 
Virtual  Ship  wiU  interface  with  operations  research  (OR).  Operations  research  has 
traditionaUy  been  concerned  with  mathematical  modelling  and  constructive 
simulation.  Measures  of  effectiveness  are  rigorously  computed,  often  exploiting 
statistical  techniques.  The  Virtual  Ship  'wiU  complement  this  capability  through  the 
fideUty  it  provides  and  through  its  ability  to  capture  human  performance 
characteristics.  The  conduct  of  OR  may  produce  a  number  of  candidate  tactics  or 
concepts  of  operations.  The  high  fidelity  representation  of  warship  operations 
pj.QYided  by  the  Virtual  Ship  wiU  aUow  these  to  be  assessed  and  refined. 
Alternatively,  the  Virtual  Ship  might  be  used  to  develop  initial  tactics  to  support  new 
systems  or  operational  concepts.  These  may  then  be  exhaustively  examined  using  the 
traditional  methodologies  of  operations  research. 

This  coUection  of  applications  is  relevant  not  only  to  the  force  in  being,  but  to  future 
concepts  for  the  maritime  force.  It  is  clear  that  the  Virtual  Ship  may  form  a  key 
component  within  the  capability  development  and  acquisition  processes.  Key  tasks 
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that  must  occur  during  these  processes  are  requirements  capture  and  tender 
assessment.  Associated  activities  include  development  of  tactics  and  training  for  new 
platforms,  operational  test  and  evaluation  and  through-life  cost  estimation.  The 
Virtual  Ship  offers  the  potential  for  exploring  new  concepts  in  a  rich  virtual 
environment  in  which  the  war  fighter  may  be  immersed.  There  is  clear  potential  to 
enhance  the  statement  of  requirement  through  this  process.  As  Defence  Industry 
makes  increased  use  of  modelling  and  simulation  in  the  development  and 
demonstration  of  their  system  capabilities,  the  possibility  will  emerge  for  this 
performance  to  be  demonstrated  within  the  Virtual  Ship.  Tendered  solutions  may  be 
exercised  in  realistic  environments  against  realistic  representations  of  the  threat.  This 
offers  the  potential  to  enhance  the  quality  of  the  acquisition  decision. 

If  the  provision  of  models  within  the  Virtual  Ship  environment  becomes  an 
established  part  of  the  acquisition  process  then  the  potential  exists  to  develop  tactics 
and  training  from  the  time  of  tender  acceptance  and  prior  to  platform  manufacture. 
The  platform  may  then  enter  service  with  crews  requiring  minimal  at-sea  training 
and  a  mature  body  of  tactical  doctrine  optimised  to  exploit  the  capabilities  of  the  new 
platform.  The  existence  of  the  Virtual  Ship  will  also  provide  a  tool  with  which 
through-life  support  issues  such  as  maintenance  and  logistical  support  may  be 
investigated.  This  offers  an  enhanced  capability  to  determine  the  total  cost  of 
platform  ownership. 

The  essential  components  of  the  Virtual  Ship  wiU  be  system  models,  the  data  that 
characterise  them  and  a  federated  architecture  within  which  these  models  are 
brought  together.  DSTO  divisions  with  particular  expertise  wiU  be  charged  with 
developing  and  maintaining  constituent  models.  The  Virtual  Ship  will  be  a  test  bed 
within  which  they  can  explore  new  concepts  within  a  simulated  operational 
environment.  It  wiU  thus  become  a  focus  for  a  wide  variety  of  DSTO  activities  that 
support  maritime  operations. 

Defence  Industry  will  play  a  significant  role  in  the  Virtual  Ship  to  support  both  the 
force  in  being  and  the  future  force  through  the  capability  development  and 
acquisition  processes.  They  will  provide  models  of  systems  that  exist  in  service  in 
order  that  the  Virtual  Ship  may  be  exploited  for  tactical  development  and  studies  of 
operational  concepts.  During  acquisitions  and  upgrades  they  will  provide  models  of 
tendered  systems  and  these  will  be  exercised  in  realistic  scenarios.  The  ability  of 
Defence  Industry  to  contribute  to  the  Virtual  Ship  is  essential  to  full  exploitation  of 
the  concept. 

The  federated  architecture  of  the  Virtual  Ship  wiU.  be  based  upon  the  US  standard  for 
distributed  simulation,  the  High  Level  Architecture  (HLA).  The  core  of  the  HLA  is 
definition  of  a  standard  for  the  exchange  of  data  amongst  simulations.  It  wiU  be 
required  to  develop  such  a  standard  for  modelling  warships  and  their  interaction 
with  external  entities.  The  existence  of  a  data  exchange  standard  enables  models  to 
be  brought  together  in  a  "plug  and  play"  fashion.  An  open  data  exchange  standard 
also  enables  Industry  to  bring  models  into  the  Virtual  Ship  whilst  retaining 
protection  of  their  Intellectual  Property,  whether  it  be  in  the  form  of  algorithms  or 
data. 

The  architecture  of  the  Virtual  Ship  wiU  allow  it  to  be  rapidly  configured  in  order  to 
address  a  particular  problem  or  apphcation.  Given  an  application,  the  requisite 
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models  will  be  identified  and  brought  together.  Consider  the  example  of  anti-ship 
missile  defence,  as  illustrated  in  Figure  1.  It  may  be  required  to  determme  how 
Infrared  Search  and  Track  (IRST)  might  be  integrated  with  an  existmg  combat  system 
in  order  to  achieve  enhanced  performance  in  this  demanding  environment.  For  this 
appUcation  models  are  required  of  the  above  water  sensors,  the  means  by jhiA 
their  data  is  fused,  the  above  water  weapons  and  countermeasures  available,  the 
command  and  control  (C^)  system,  communications,  vessel  propulsion  and 
vulnerability.  In  the  context  of  the  existing  maritime  force,  models  assoaated 
the  underwater  environment  are  not  required.  The  High  Level  Architectoe  (^A) 
provides  the  technical  "glue"  which  binds  the  separate  models  mto  an  mtegrated 
simulation  of  the  warship. 


System  models - ►  Application/problem - ►  Virtual  Ship 


Radar  — 
ESM  - 
IRST  - 
Active  sonar 
Passive  sonar 
EM  data  fusion  - 
Sonar  data  fusion 
Above  water  weapons  - 
Underwater  weapons 
Above  water  countermeasures  - 
Underwater  countermeasures 

system  — | 
Communications  - 
Propulsion  - 
Vulnerability  - 


Anti-ship 
missile  defence 

High  Level  Architecture  (HLA) 


Open  data  exchange  standard 


Virtual  Ship 
instantiation 
tailored  to  the 
application 


Fime  1:  An  iUnstratim  ofhmn  the  federated  Virtml  Ship  Architecture  embks  ite  Virbml 
Ship  to  he  customised  to  the  problem  at  hand.  In  this  case  it  is  anti-ship  missile 

deduce. 


This  example  illustrates  an  essential  characteristic  of  the  Virtual  Ship.  It  is 
composable  to  the  level  of  complexity  required  to  satisfy  a  particular  objective.  In 
some  application  domains,  only  two  models  may  be  needed  in  order  to  address  a 
problem.  In  others  a  full  simulation  of  warship  functionality  may  be  required  to 
capture  the  rich  set  of  interactions  amongst  many  complex  systems  and  the  people 
who  operate  them.  The  ability  to  compose  the  Virtual  Ship  with  few  or  many  models 
wiU  result  in  versions  existing  throughout  DSTO  and  Defence  Industry.  Where  a 
class  of  problems  may  be  addressed  completely  within  a  given  technology  or  warfare 
area,  a  version  of  the  Virtual  Ship  may  be  used  in  which  only  models  within  this 
dorriain  are  brought  together.  These  components,  however,  will  be  compatible  with 
those  from  other  domains  and  may  thus  be  mtegrated  to  explore  issues  across 
technology  and  warfare  areas. 

The  basis  of  the  Virtual  Ship  upon  the  HLA  wiU.  provide  natural  interoperability 
with  virtual  air  and  land  environments,  as  well  as  those  of  the  US  and  UK.  The 
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Virtual  Ship  will  thus  provide  an  essential  component  in  addressing  issues  of  joint 
and  coalition  warfare. 

This  report  is  a  contribution  to  the  process  of  establishing  a  shared  imderstanding  of, 
and  vision  for,  the  Virtual  Ship  concept.  To  achieve  this,  section  2  describes  a  number 
of  specific  applications  of  die  Virtual  Ship.  These  range  across  technology  and 
warfare  areas  and  demonstrate  the  scope  of  the  concept.  Many  of  these  applications 
emphasise  placing  humans  in  the  simulation  loop  in  order  to  imderstand  tiieir 
contribution  to  system  performance.  This  consideration  naturally  alludes  to  the  role 
the  Virtual  Ship  may  play  in  support  of  training  and  mission  rehearsal.  This  is 
discussed  in  section  3. 

The  Virtual  Ship  will  share  a  close  relationship  with  traditional  operations  research. 
The  impact  of  a  Virtual  Ship  capability  upon  the  conduct  of  OR  is  discussed  in 
section  4,  and  the  nature  of  the  relationship  between  these  capabilities  is  explored. 
The  concept  that  unifies  them  is  that  of  supporting  military  decision-making. 

The  potential  role  of  the  Virtual  Ship  in  the  acquisition  process  is  discussed  in  section 
5.  There  is  particular  description  of  the  Simulation  Based  Acquisition  (SBA) 
movement  in  the  US.  The  objective  of  SBA  is  to  integrate  use  of  modelling  and 
simulation  with  all  phases  of  the  platform  acquisition  process.  There  are  two 
essential  elements  in  achieving  this.  One  is  technical  and  concerns  development  of  a 
common  technical  framework  for  modeUing  and  simulation.  This  is  essential  in 
promoting  re-use  of  simulation  components  across  applications  and  in  establishing 
common  virtual  environments  within  which  competing  systems  may  be  fairly 
assessed.  The  second  component  of  SBA  concerns  a  process  for  acquisition  that 
exploits  modelling  and  simulation.  The  key  concept  here  is  the  Integrated  Product 
Team  (IPT),  which  brings  together  aU  those  with  a  stake  in  the  acquisition  process  at 
the  earliest  stage. 

The  architecture  of  the  Virtual  Ship  is  discussed  in  section  6  and  the  relevant 
characteristics  of  the  High  Level  Architecture  are  described.  The  Virtual  Ship 
Architecture  (VSA)  consists  of  those  components  required  to  simulate  warship 
operations,  over  and  above  the  components  of  the  HLA.  These  are  presented  and 
their  characteristics  described.  There  is  also  discussion  of  issues  associated  with 
management  of  the  Virtual  Ship  and  this  includes  computer  hardware  and  software, 
security  and  configuration  control. 

The  provision  and  collection  of  data  are  essential  processes  associated  with  the 
Virtual  Ship.  Section  7  discusses  the  provision  of  data  to  support  simulation  and  the 
collection  of  data  during  simulation  to  facilitate  analysis  and  decision  making.  An 
essential  component  of  distributed  simulation  is  the  use  of  common  data  sources  by 
different  models.  Methodologies  and  tools  that  might  support  this  are  discussed, 
including  establishment  of  data  standards. 

The  role  of  Industry  in  the  Virtual  Ship  and  mechanisms  to  support  their 
participation  are  discussed  in  section  8.  The  way  ahead  for  the  Virtual  Ship  is 
outlined  in  section  9. 
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2.  Application  of  the  Virtual  Ship  -  Narratives 

The  tasks  of  defining  the  constituent  parts  of  the  Virtual  Ship,  developing  detailed 
guidelines  for  its  use  and  appreciating  its  relationship  with  a  range  of  defence 
activities,  including  research,  capability  development  and  acquisition,  are  assisted 
through  development  of  a  number  of  use  scenarios.  This  section  describes,  in 
narrative  form,  a  nximber  of  scenarios  in  which  the  Virtual  Ship  offers  positive  utility, 
that  is  it  makes  a  positive  contribution  in  achieving  some  defence  objective.  The 
examples  have  been  chosen  to  reflect  a  range  of  technological  issues  tiiat  face 
maritime  forces.  They  cover  above  and  tmderwater  warfare,  and  include  specific 
technological  issues  relating  to  platforms  and  communications. 


2.1  Air  Defence  Coordination  and  Cooperative  Engagement 
Capability! 

Anti-ship  missiles  pose  a  major  threat  to  warships.  Their  speed  and  sea  skimmmg 
capability  cause  two  mutually  enhancing  problems.  Their  trajectory  makes  them 
difficult  to  detect.  The  late  time  of  detection  coupled  with  their  speed  requires  a 
defensive  response  within  a  severe  time  constraint.  A  subsonic  missile  detected  at  the 
horizon  demands  a  response  within  80  seconds.  When  the  missile  travels  at  Mach  3 
the  time  available  for  self-defence  is  20  seconds. 

The  response  to  these  demands  requires  optimum  exploitation  of  technological 
advances  in  sensors,  weapon  systems  and  countermeasures.  Above  aU  else,  the 
significant  requirement  is  to  exploit  the  data  provided  by  multiple  sensors  and  the 
distinctive  capabilities  of  new  weapons  and  coxmtermeasures  in  order  to  implement 
the  optimum  self  defence  solution.  The  principal  task  of  the  command  and  control 
system  is  to  provide  the  commander  with  useful  information  in  a  timely  manner  and 
tiie  means  for  implementing  decisions.  Integration  of  sensor  and  weapon  data  is 
critical  in  this  regard.  In  a  heightened  threat  environment,  failure  to  optimise  the 
allocation  of  resources  such  as  weapons,  sensors  and  countermeasures  could  have 
catastrophic  consequences. 

High  priority  research  is  the  development  of  enhanced  algorithms  for  allocating 
weapons  and  coimtermeasures  in  response  to  the  anti-ship  missile  threat.  This  is  the 
hard  kill/ soft  kill  optimisation  problem.  Implicit  within  this  program  is  a 
requirement  to  characterise  the  performance  of  existing  and  future  sensors,  weapons 
and  countermeasures.  Typical  examples  include  phased  array  radar,  the  Evolved  Sea 
Sparrow  Missile  (ESSM)  and  the  NULKA  active  countermeasure.  Performance 
cJiaracterisation  in  the  context  of  weapon  and  countermeasure  allocation  and  fire 
control  is  at  the  heart  of  the  integration  problem. 

Once  algorithms  have  been  developed  it  remains  to  assess  their  operational  efficacy 
and  particularly  their  performance  as  part  of  a  system  in  which  a  key  component  is 
the  command  team.  It  is  this  role  that  is  ideally  suited  to  the  Virtual  Ship.  An 
operations  room  may  be  configured  to  represent  in-service  platforms.  Models  of  the 
ship's  sensors,  coimtermeasures  and  weapon  systems  wiU  be  brought  together  with  a 


1  This  section  prepared  in  collaboration  with  Dr  Darren  Sutton  of  Weapon  Systems  Division,  Mr  Grant 
Horsfall  of  Electronic  Warfare  Division  and  Dr  Jonathan  Legg  of  Surveillance  Systems  Division. 
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model  of  the  O  system.  Indeed,  the  heart  of  the  O  model  may  be  the  actual  system 
software,  with  a  simple  interface  that  allows  its  inputs  and  outputs  to  be  compatible 
with  simulated  components.  The  algorithms  developed  for  weapon  and 
countermeasure  allocation  will  be  embedded  within  the  O  model. 

A  command  team  will  be  brought  together  within  the  Virtual  Ship  operations  room. 
They  will  conduct  air  warfare  operations  in  a  virtual  environment  that  represents 
with  high  fidelity  perceived  threat  scenarios.  The  threats  will  be  provided  by  DSTO 
developed  models,  re-engineered  to  operate  within  the  Virtual  Ship  simulation 
environment.  The  use  of  high  fidelity  models  of  the  physical  environment  and 
electromagnetic  propagation  will  permit  assessment  of  performance  within  the 
unique  conditions  of  our  region. 

This  exercise  will  provide  realism  just  short  of  actually  putting  a  ship  to  sea.  Indeed, 
the  ability  to  realistically  represent  threat  weapons  may  actually  provide  a  benefit 
beyond  tiiat  which  can  be  achieved  during  exercises.  In  addition  to  assessing 
questions  of  platform  sxirvivability,  the  command  team  will  be  able  to  exercise  their 
operating  procedures  and  optimise  them  in  a  manner  that  exploits  the  capability 
offered  by  the  new  algorithms.  The  essential  contribution  of  the  human  operator  to 
the  whole  system  may  thus  be  accoimted  for  in  optimisation  of  performance  and  the 
merits  of  automating  aspects  of  ship  defence  may  be  assessed. 

A  similar  use  of  the  Virtual  Ship  will  support  development  of  technological  solutions 
that  implement  the  new  network  centric  warfare  paradigm  of  air  defence.  Here  the 
problem  is  integration  of  tactical  data  from  multiple  sources,  and  particularly  the 
sensor  data  from  all  parts  of  a  task  force.  Air  defence  is  achieved  through  optimxim 
allocation  of  the  weapon  systems  and  countermeasiues  of  the  whole  task  force.  The 
allocation  problem  is  greater  in  extent  and  is  exacerbated  by  the  requirement  to 
effectively  communicate  tactical  and  inteUigence  data  amongst  multiple,  and 
possibly  remote,  units.  The  communications  aspect  is  highlighted  in  the  next 
scenario. 

2.2  Evaluation  and  Exploitation  of  Emerging  Communications 
Technology^ 

Emerging  communications  technologies  have  the  potential  to  revolutionise 
approaches  to  warfare.  Particular  attributes  of  this  technology  are  high  bandwidth 
and  the  ability  to  communicate  reliably  in  real  time  across  intercontinental  distances. 
The  key  challenge  in  exploiting  these  attributes  is  integration  of  the  commimications 
infrastructure  with  an  information  management  strategy  that  optimises  operational 
effectiveness.  Research  is  tmderway  within  Communications  Division  in  order  to 
meet  this  challenge. 

The  basic  requirements  of  future  network  configurations  have  been  identified  in  a 
number  of  reports^^-s  These  are: 


2  This  section  prepared  in  collaboration  with  Dr  Greg  Simms  and  Mr  Anthony  Ween  of 
Communications  Division. 

5  Royal  Australian  Navy  Communications  and  Information  Systems  Review  (RANCIS),  Phase  II, 
RANCIS  team,  sponsored  by  Deputy  Chief  of  Navy,  1997 
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1.  Shore  based  strategic  and  operational  sites  requiring  wideband  communications 
connectivity  to  other  land  based  assets. 

2.  Provision  of  high  bandwidth  wide  area  communications  to  mobile  or  deployed 

3.SS6^S 

3.  Advanced  information  processing  and  handling  capabilities  on  board  mobile  or 
deployed  assets  so  they  can  effectively  utilise  available  communicatiorrs  hnks. 

Two  technical  approaches  to  the  determination  of  the  capability  improvement 
offered  by  modem  communications  technology  are  currently  xmder  consideration. 
One  option  is  to  integrate  the  physical  communications  infrastmcture  with  the 
Virtual  Ship.  An  alternative  approach  is  to  simulate  the  communications 
infrastmcture.  Either  option  wiU  facilitate  realistic  simulation  of  the  performance  of  a 
deployed  task  group  utilising  modem  communications  links.  The  nodes  of  the 
communications  network  will  include  instantiations  of  the  Virtual  Ship,  configured 
to  exploit  the  enhanced  information  availability.  Maritime  communications  and 
information  management  may  be  observed  and  processes  determined  to  evaluate 
capability  improvements.  The  emphasis  will  be  on  processes  and  doctrine. 

Particular  issues  that  may  be  addressed  through  the  Virtual  Ship  include: 

1.  Assessment  of  the  operational  effectiveness  of  emerging  maritime  services,  such 
as  the  Joint  Command  Support  Environment  (JCSE).  JCSE  provides  a  situational 
awareness  picture,  data  base  capabihties  for  logistics  purposes,  planning  aids, 
office  automation  capabilities  and  additional  functions.  In  the  longer  term,  the 
aim  is  to  provide  broadband,  ADF  wide  services. 

2.  Evaluation  of  the  operational  effectiveness  of  duplex  satcom  Hnks  and  an  UHF 
LOS  hnk.  In  the  future,  assessments  wiU  be  made  of  theatre  broadcast  beams  for 
high  data  rate,  spot  beam  data  delivery,  an  assortment  of  redimdant  backup  links 
(Iridium)  and  emerging  allied  and  domestic  technologies. 

3.  Evaluation  of  the  operational  utiHty  offered  by  alternative  intra-ship  network 

architectures,  and  particularly  the  provision  of  LANs  at  different  classification 
levels.  This  assessment  wiU  be  facilitated  through  integration  of  Virtual  Ship 
system  models,  including  the  system,  sensors  and  weapons. 


2.3  Evaluating  the  Smart  Ship^ 

A  major  trend  in  warship  system  evolution  is  the  incorporation  of  reduced  manning 
concepts  as  integral  to  the  platform  operation.  The  US  Navy  have  trialed  this  on 
board  the  USS  Yorktown,  a  Triconderoga  class  cruiser.  Through  a  combination  of 
technology  initiatives,  organisational  change  and  procedural  modifications, 
significant  reduction  in  manpower  has  been  achieved  without  a  measurable 
reduction  in  platform  capability. 


^  Project  Marigold  Report,  Maritime  Command,  1995;  Revised  Version  by  Maritime  Command  and 
DSTO,  1997 

5  DSTO  report  SEA  1442 

*  This  section  prepared  in  collaboration  with  Mr  Kevin  Gaylor  of  Maritime  Platforms  Division. 
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The  technology  initiatives  included  systems  such  as  an  integrated  bridge,  integrated 
condition  assessment,  monitoring  and  control,  damage  control,  a  fibre  optic  LAN 
and  a  wireless  voice  communication  system. 

Research  is  being  conducted  in  the  Maritime  Platforms  Division  (MPD)  to  examine 
the  US  Smart  Ship^  program  and  its  follow-on  developments  in  the  surface 
combatant  SC-21  program®,  and  assess  the  potential  benefits  of  some  of  these  systems 
for  the  RAN.  In  addition,  MPD  currently  has  a  well  established  research  program  in 
the  areas  of  damage  control  systems  and  vulnerability  assessment  that  relates 
directly  to  some  of  the  Smart  Ship  initiatives. 

MPD  is  developing  a  program  based  on  a  Virtual  Platform  which,  when  integrated 
with  the  Virtual  Ship,  wiU  provide  a  capability  to  assess  advanced  platform 
management  systems  and  procedures.  The  Virtual  Platform  will  consist  of  common 
core  information  that  is  a  combination  of  geometric  and  non-geometric  engineering 
data  describing  the  physical  and  logical  configuration  of  the  ship,  and  a  number  of 
models  and  databases  relating  to  platform  management  and  behaviour.  These 
models  and  databases  wiU  be  initially  based  on  current  MPD  research  areas  and 
extend  into  new  areas  currently  xmder  development. 

As  an  example  of  how  the  Virtual  Platform  will  integrate  with  the  Virtual  Ship, 
consider  the  Air  Defence  Coordination  and  Cooperative  Engagement  Capability 
example  outiined  previously.  If  a  missile  hits  the  platform  during  a  simulated 
engagement,  the  Virtual  Ship  can  determine  the  extent  of  damage  to  the  platform 
and  all  the  systems  effected.  A  damage  management  team  can  then  exercise  various 
damage  control  options  to  restore  capability  to  the  platform  in  tire  most  effective 
manner,  balancing  requirements  for  damage  repair  time,  self-protection  and 
operational  effectiveness.  Various  physical  layouts  of  the  platform  can  be  exercised 
to  determine  the  most  effective  physical  and  logical  configuration,  especially  in 
regard  to  separation  and  redrmdancy  of  critical  platform  systems.  The  effect  of 
reduced  manning  in  this  critical  circumstance  may  also  be  assessed.  Thus  the  Virtual 
Ship,  together  with  a  Virtual  Platform,  can  be  used  to  develop  effective  platform 
survivability  strategies,  both  in  the  platform  design  stage  and  in  support  of  the  force 
in  being. 

2.4  Surface  Ship  Torpedo  Defence^ 

Torpedoes  pose  a  significant  threat  to  surface  ships.  Advances  in  technology  have 
resulted  in  significantly  more  capable  and  quieter  torpedoes  becoming  available  in 
Austraha's  area  of  strategic  interest.  The  timely  detection  of  these  modem  torpedoes 
over  all  potential  directions  of  attack  poses  a  significant  challenge.  The  provision  of 
all  round  coverage  to  a  useful  detection  range  requires  the  use  of  aU  available 
sensors,  including  hull  moxmted  sonars,  obstacle  avoidance  sonars,  towed  array 
sonars  and  sonobuoys.  Even  if  the  weapon  is  detected,  suitable  cotmtermeasures 
need  to  be  developed  and  evaluated. 


’’  http:/ /www.dt.navy.mil/ smartship/ 

®  http:/ /sc21.crane.naw.mil/ 

®  This  section  prepared  in  collaboration  with  Mr  Graeme  Manzie,  Dr  David  Kershaw  and  Mr  Simon 
Taylor  of  Maritime  Operations  Division. 
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The  use  of  semi-analytical  models,  typical  of  operations  research,  have  the  benefit  of 
a  small  run  time,  and  thus  can  be  used  in  a  Monte  Carlo  fashion  to  provide  statistical 
measures  of  countermeasure  effectiveness.  However,  these  models  are  typicaUy  of 
modest  fidelity  and  may  neglect  many  crucial  complexities,  such  as  the  actual 
performance  of  the  ship's  sonars  and  the  manoeuvrability  of  the  target  platform. 

The  Virtual  Ship  wiU  provide  a  welcome  additional  technique  with  which  to 
investigate  this  problem.  Key  aspects  that  require  investigation  are  the  abiUty  of  the 
surface  ship  to  detect  the  threat  via  a  number  of  sensors,  the  ability  to  fuse  the  sensor 
data  to  potentially  improve  the  detection  range,  and  its  ability  to  perform  the 
requisite  countermeastue  to  negate  the  weapon.  Thus  a  Virtual  Ship  would  be 
configured  with  high  fidehty  models  of  the  ships  sonars,  integrated  sonar  processing 
and  a  high  fidelity  model  of  the  vessel  hydrodynamics  and  propulsion.  The  scenano 
would  provide  a  model  of  the  threat  torpedo  with  a  realistic  representation  of  its 
dynamics  and  acoustic  output. 

Within  the  Virtual  Ship  a  command  team  will  occupy  the  operations  room.  They  wih 
detect  the  torpedo  threat  through  their  sonar  displays  and  seek  to  implement  the 
response  as  suggested  by  operatioris  research.  The  conduct  of  a  number  of  scenarios 
will  permit  assessment  of  three  principal  aspects;  can  the  torpedo  be  detected 
sufficiently  soon  that  countermeasures  may  be  implemented,  if  so  can  the  ship  carry 
out  the  coimtermeasures,  and  if  so  are  they  effective. 

The  use  of  the  Virtual  Ship  in  this  example  aUows  investigation  of  the  interplay 
between  the  time  of  threat  detection  and  the  subsequent  response.  This  is  a 
particularly  important  aspect  of  surface  ship  torpedo  defence  noting  the 
improvements  in  torpedo  technology  and  the  increasing  submarine  threat  in  our 
region.  This  interplay  cannot  currently  be  achieved  in  any  other  way  even  in  physical 
exercises  since  we  do  not  possess  exercise  torpedoes  of  advanced  technology  (eg 
wake  homers,  quiet  electric) .  It  wiU  allow  candidate  detection  systems  and 
countermeasmes  to  be  investigated  in  a  highly  realistic  environment  short  of  putting 
experisive  ship  and  submarine  assets  to  sea.  The  time  and  cost  savings  will  be 
considerable. 

2.5  Integrated  Undersea  Warf  are^o 

In  recognition  of  the  threat  posed  by  torpedoes  to  surface  ships,  there  are  a  number 
of  major  projects  currently  underway,  the  objective  of  which  is  to  enhance  the  Anti- 
Submarine  Warfare  (ASW)  capability  of  surface  ships.  These  include: 

1.  SEA  1100  -  Australian  Surface  Ship  Towed  Array  Sonar  System  (ASSTASS).  The 
current  phase  of  this  project  concerns  evaluation  of  the  operational  effectiveness 
of  two  towed  Low  Frequency  Active/ Passive  Sonars  (LFAPS)  to  enable  the  ADF 
to  become  smart  buyers  for  the  next  phase,  in  which  LFAPS  will  be  fitted  to  the 
ANZAC  and  FFG  frigates.  The  system  currently  being  evaluated  is  a  stand-alone 
monostatic  towed  array  based  system  that  includes  passive  and  active  processing 
as  weU  as  a  sonobuoy  processor. 


10  This  section  prepared  in  collaboration  with  Mr  Simon  Taylor  of  Maritime  Operations  Division. 
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2.  SEA  1390  -  FFG  Upgrade  (FFGUP).  This  project  funds  a  major  upgrade  to  the 
weapon  systems  including  the  replacement  of  the  hull  mounted  sonar  with  a 
broadband  COTS  based  system,  the  addition  of  an  obstacle  avoidance  sonar  and 
a  torpedo  defence  system. 

3.  SEA  1443  -  ANZAC  Warfightmg  Improvement  Program  (WIP).  The  WIP 
provides  systems  to  upgrade  the  warfighting  capability  of  the  ANZAC  frigates, 
including  the  addition  of  an  obstacle  avoidance  sonar  and  a  torpedo  defence 
system. 

4.  SEA  1405  -  Seahawk  MidHfe  Upgrade  (SMU).  The  SMU  wiU  investigate  options 
for  upgrading  the  capability  of  the  organic  Seahawk  helicopter  to  ensure  it 
provides  an  effective  operational  capability  for  the  remainder  of  its  life.  This 
project  will  evaluate  the  acoustic  sensors  including  passive  and  active  sonobuoys, 
multistatic  systems  and  dipping  sonars. 

Each  of  the  above  projects  aims  to  improve  the  capability  of  surface  warships  by 
providing  stand-alone  sensors  that  operate  mono-staticaUy.  There  is  clear  potential  to 
improve  capability  through  the  integration  of  data  from  a  number  of  acoustic 
sensors,  including  hull  mormted  and  towed  array  sonars,  and  sonobuoys  that  may  be 
deployed  directly  from  a  warship  or  by  its  organic  air  assets.  The  term  integrated 
tmdersea  warfare  refers  to  this  methodology. 

A  significant  advantage  offered  by  integration  of  sonar  data  from  multiple  sensors  is 
that  of  an  enhanced  signal-to-noise  ratio.  Additional  advantage  might  be  obtained 
through  the  arrangement  of  a  bi-static  or  multi-static  geometry  amongst  sonar 
sources,  scattering  targets  and  acoustic  detectors.  Such  an  arrangement  enhances  the 
probability  that  at  least  one  of  the  many  detectors  wiE  receive  a  significant  echo  from 
the  target. 

There  are  a  number  of  challenges  in  implementing  an  integrated  undersea  warfare 
capability.  The  means  of  integrating  sonar  data  needs  be  determined,  as  do  the 
communications  required  to  pass  data  from  off-board  sensors  to  tire  ship.  New 
tactics  are  required  to  optimally  exploit  the  technological  possibilities  and 
development  of  tactical  aids  is  critical  in  this  regard. 

Although  analytical  studies  wiU  provide  a  degree  of  tmderstanding  of  the  benefits  of 
integrated  undersea  warfare  and  recommendations  for  candidate  tactics,  a  true 
tmderstanding  of  the  benefits  is  critically  dependent  upon  an  appreciation  of  the 
operational  procedxues  required  to  implement  tactics.  The  Virtual  Ship  configured 
with  high  fidelity  models  and  operators  in  the  loop  wUl  permit  development  of 
initial  tactics  and  operating  procediues.  The  appreciation  of  operational 
requirements  is  an  essential  component  in  the  design  and  implementation  of 
supporting  tactical  aids. 
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3.  Training  and  Mission  Rehearsal 

The  ability  to  replicate  the  operations  room  of  platforms  in  service  wiU  provide  a 
natural  training  facility.  Particularly  advantageous  will  be  the  capability  to  represent, 
with  high  fidelity,  the  threat  environment,  including  platforms,  weapons  and  critical 
physical  effects,  such  as  those  associated  with  propagation. 

The  integration  of  models  across  the  spectrum  from  the  threat  to  the  own  ship 
combat  system  to  the  physical  platform  itself  will  enable  comprehensive  training  of  a 
command  team.  This  wiU  include  mission  planning,  engagement  with  the  enemy  and 
post-engagement  issues  such  as  damage  control  and  restoration  of  fighting 
capability. 

The  basis  of  the  Virtual  Ship  upon  distributed  simulation  will  facilitate  its  connection 
with  existing  simulation  based  training  systems  in  order  to  create  more  complex 
training  scenarios.  In  this  manner  the  Virtual  Ship  will  enhance  the  capability  being 
dehvered  by  project  SEA  1412.  This  project  concerns  linking  existing  RAN  team 
based  training  simulation  systems  using  the  Distributed  Interactive  Simulation  (DIS) 
protocol.  The  migration  from  DIS  to  HL A  is  a  low  risk  exercise  and  it  has  already 
been  demonstrated  that  DIS  based  and  HLA  based  simulations  may  be  directly 
linked.  It  will  be  possible  to  link  multiple  versions  of  the  Virtual  Ship  with  existing 
RAN  systems  in  order  to  create  complex  multiple  ship  training  scenarios. 

Exploitation  of  the  distributed  simulation  capability  to  operate  over  large 
geographical  separations  wffl  enable  a  revolution  in  the  way  operations  are  prepared 
for,  particularly  with  regard  to  mission  rehearsal.  Future  systems  will  have  training 
systems  embedded  within  them  which,  for  the  most  part,  utilise  the  operational 
hardware  and  software.  These  embedded  training  systems  will  include  scenario 
generators  that  provide  the  appropriate  stimuli  so  that  they  may  be  operated 
realistically  and  thus  used  to  derive  training  benefit.  A  distributed  simulation 
capability  will  enable  these  stimuli  to  be  generated  by  manned  simulators  that  are 
remote  from  the  operational  unit,  or  by  other  operational  units  that  are  remote  and 
utilising  their  embedded  trainers. 

These  possibilities  will  enable  units  to  rehearse  in  a  common  virtual  operational  area, 
despite  being  geographically  remote.  This  may  occiu  when  remote  units  on  patrol 
are  required  to  inarry  in  order  to  conduct  an  operation  in  response  to  a  crisis  or 
threat  escalation.  The  units  will  be  able  to  conduct  mission  rehearsal  en  route  to  the 
area  of  operations.  Not  only  will  this  enable  offensive  action  to  be  launched  sooner, 
but  also  operational  plans  may  be  optimised  through  the  abiHty  to  exercise  them  via 
distributed  simulation. 

The  basis  of  the  Virtual  Ship  upon  the  HLA  will  provide  natural  interoperability 
with  simulation  systems  in  the  air  and  land  domain,  and  those  of  our  allies, 
particularly  the  US  and  UK.  Virtual  exercises  of  joint  and  coaUtion  forces  will  be 
possible,  as  will  mission  rehearsal. 
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4.  Relationship  to  Operations  Research 

As  the  Virtual  Ship  evolves  its  application  will  require  new  thinking  as  to  how  such  a 
capability  may  be  employed  to  support  defence  objectives.  Consideration  of  its 
relationship  with  operations  research  offers  guidance  in  this  regard. 

Operations  research  typically  involves  simulation  of  some  military  activity  or 
operation.  Many  replications  of  the  model  within  a  common  scenario  are  often 
performed,  with  some  randomness  introduced  in  order  to  replicate  uncertainties  in 
the  real  world.  On  the  basis  of  these  replications,  statistical  measures  of  effectiveness 
are  compiled.  It  must  also  be  noted  that  these  models  often  encapsulate  human 
decision  making  in  some  algorithmic  form.  As  a  consequence  their  output  may  not 
reflect  the  richness  of  behaviour  that  is  evident  in  human  systems. 

A  key  aspect  of  the  Virtual  Ship  will  be  its  abihty  to  put  humans  in  the  simulation 
loop.  As  a  consequence  these  simxilations  will  be  nm  at,  or  near,  real  time.  There  are 
two  consequences  of  this.  The  requirement  to  run  at  real  time  will  prevent  the 
performance  of  many  replications  of  a  given  scenario.  The  presence  of  a  human  will 
introduce  a  number  of  effects  that  render  any  replications  statistically  dependent. 
Both  these  factors  wiQ  militate  against  using  the  Virtual  Ship  to  construct 
performance  measures  in  the  traditional  way.  New  thinking  is  required  as  to  how  the 
Virtual  Ship  might  best  be  employed. 

As  guidance  on  this  issue  it  is  important  to  note  the  essential  role  that  operations 
research  plays  in  the  military  context.  This  role  is  one  of  supporting  decision  making. 
It  provides  data  which  guides  the  thinking  of  those  charged  with  making  decisions, 
whether  they  pertain  to  acquisition  or  operational  matters. 

The  role  of  the  Virtual  Ship  will  therefore  be  to  support  decision  making  throughout 
the  whole  of  the  platform  lifecycle.  Although  the  Virtual  Ship  may  be  configured 
without  a  human-in-the-loop  and  thus  used  as  a  traditional  operations  research  tool, 
its  principal  contribution  will  be  through  the  ability  to  capture  htunan  behaviour  and 
decision  making  and  to  visualise  scenarios  with  a  high  degree  of  realism.  The  data  so 
obtained  will  be  more  quatitative  than  quantitative.  The  Virtual  Ship  will  provide  an 
environment  within  which  decision  makers  can  visuailise  scenarios,  work  through 
the  consequences  of  actions  and  provide  themselves  with  an  enhanced  capability  to 
exercise  their  judgement. 

The  existence  of  such  a  capability  will  in  no  way  diminish  the  role  of  traditional 
operations  research.  Indeed,  the  Virtual  Ship  will  provide  an  additional  tool  that  wiU 
both  take  input  from,  and  provide  input  to,  traditional  operations  research 
methodologies.  For  example,  a  traditional  operations  research  approach  may  be 
appHed  to  a  problem  of  tactical  development  and,  on  the  basis  of  this,  several 
candidate  tactics  may  be  proposed.  These  may  then  be  trialed  in  the  Virtual  Ship, 
prior  to  any  attempt  to  conduct  expensive  sea  trials.  This  offers  a  number  of 
advantages.  First,  the  Virtual  Ship  will  provide  a  higher  fidelity  modeUing 
environment  and  therefore  provide  a  more  rigorous  assessment  of  the  feasibility  of 
the  candidate  tactics.  Second,  apphcation  of  the  Virtual  Ship  will  allow  an  assessment 
to  be  made  of  the  means  by  which  the  tactic  may  be  implemented,  that  is  the 
operational  procedures  required  to  implement  it  may  be  determined  in  the  realistic 
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virtual  environment  Indeed,  it  may  be  that  matters  concerning  the  human 
contribution  to  the  total  system  may  affect  the  ability  to  implement  a  tactic  to  a 
greater  extent  than  the  physical  aspects  considered  in  the  traditional  operations 

research  approach. 

The  reverse  process,  whereby  the  Virtual  Ship  provides  data  for  operations  research, 
will  occxir  when  a  mature  and  validated  Virtual  Ship  capability  exists.  Certain 
performance  parameters  required  for  operations  research  are  often  measured  using 
trials  procedures.  The  Virtual  Ship  offers  a  cost  effective  alternative  to  this.  The 
circumstance  may  also  arise  where  experimentation  using  the  Virtual  Slup  provides 
results  that  motivate  the  performance  of  a  detailed  study  utilising  traditional 
operations  research  techniques.  It  may  be  that  a  promising  tactic  developed  in  the 
Virtual  Ship  requires  analysis  in  a  range  of  scenarios  that  would  be  prohibitive  if 
performed  in  the  Virtual  Ship  with  the  human-in-the-loop.  This  is  another  example 
of  the  interplay  between  the  Virtual  Ship  and  operations  research  illustrating  the 
enhanced  capability  achieved  through  their  mutual  exploitation. 


5.  Application  to  the  Acquisition  Process 

A  significant  characteristic  of  simulation  is  that  it  may  represent  systems  that  have 
yet  to  be  constructed.  As  a  consequence,  not  oidy  may  the  Virtual  Ship  represent 
platforms  in  service,  it  may  represent  concepts  for  future  platforms.  These  may  be 
exercised  in  realistic  environments  and  threat  scenarios  in  order  to  assess  their 
operational  utility.  It  is  therefore  evident  that  the  Virtual  Ship  concept  may  be 
exploited  in  support  of  the  acquisition  of  new  maritime  platforms.  In  order  to 
appreciate  the  contribution  that  the  Virtual  Ship  might  make  to  the  acquisition 
process  it  is  appropriate  to  review  the  Simulation  Based  Acquisition  (SBA) 
movement  being  led  by  the  US. 

Simulation  Based  Acquisition  is  a  revolutionary  approach  to  military  acquisition.  The 
core  of  SBA  is  exploitation  of  modelling  and  simulation  throughout  the  acquisition 
process  in  order  to  field  high  technology  systems  in  shorter  time-scales,  with  reduced 
cost  and  technical  risk. 

There  are  many  applications  of  simulation  throughout  tiie  acquisition  process. 
Simulation  may  be  used  to  construct  virtual  concept  systems  and  as  a  basis  for 
capturing  requirements.  Indeed,  aspects  of  the  simulation  may  be  used  to  specify  the 
requirement.  Solutions  to  requirements  may  be  tendered  in  the  form  of  simulations, 
where  the  systems  may  be  assessed  in  virtual  environments  and  relevant  threat 
scenarios.  The  particular  benefit  of  this  approach  is  that  the  operational  utility  of  tiie 
system  may  be  assessed  without  the  requirement  to  actually  build  a  platform.  This 
process  will  crucially  engage  the  warfighter  in  the  process  of  equipment  selection. 

During  the  design  phase  reviews  will  be  facilitated  through  use  of  advanced 
computer  aided  design  technologies.  The  physical  models  of  old  wiU  be  replaced  by 
virtual  representations  in  which  virtual  operators  may  interact  with  the  system  or 
platform  in  order  to  assess  aspects  like  ergonomics  and  maintainability.  It  is  through 
these  aspects  that  logistic  support  requirements  can  be  foreseen  and  their 
contribution  to  whole  of  life  cost  reliably  estimated. 
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Models  of  ship  systems  will  be  designed  to  interface  with  computer  aided  design 
tools,  or  to  directly  use  their  output.  In  this  way,  a  methodology  is  identified 
whereby  an  assessment  of  tiie  operational  impact  of  alterations  in  the  physical  design 
may  be  immediately  explored.  As  an  example,  suppose  a  physical  design  option 
concerns  the  height  of  the  mast,  with  a  consequent  impact  on  the  height  of  certain 
sensors.  Data  from  the  relevant  design  tool  may  be  fed  directly  into  the  Virtual  Ship 
in  order  to  explore  the  impact  of  this  upon  detection  of  above  water  threats,  and  the 
effect  of  the  changed  mass  distribution  on  the  hydrodynamics  of  the  vessel. 

Ultimately,  an  entire  system  will  be  designed  in  virtual  form.  The  existence  of  a 
virtual  design  will  facilitate  the  mcorporation  of  new  technology,  especially  that 
from  rapidly  advancing  fields  such  as  information  and  digital  technology.  This 
characteristic  will  reduce  the  prospect  of  obsolescence  and  reduce  the  risk  associated 
with  the  construction  of  platforms.  It  will  further  enable  multiple  platforms  of  a 
given  class  to  evolve  as  they  are  built,  so  that  each  comes  into  service  with  maximum 
technology  insertion. 

By  the  time  construction  begins  a  rich  and  versatile  set  of  simulation  tools  describing 
the  platform  will  exist.  These  will  facilitate  the  immediate  development  and  conduct 
of  training.  Tactical  development  may  also  proceed  so  that  the  introduction  of  the 
platform  into  service  is  accompanied  by  mature  doctrine.  This  will  coi\siderably 
reduce  the  time  from  system  conception  to  operational  use  that  exploits  all  the 
capabilities  that  new  technology  offers. 

The  ability  to  compreherisively  model  the  platform  will  also  support  the  conduct  of 
Operational  Test  and  Evaluation  (OT&E).  Trials  can  be  designed,  with  particular 
emphasis  on  determination  of  appropriate  scenarios  and  data  acquisition  strategies. 
The  prospect  is  to  reduce  the  time  required  for  OT&E  and  enhance  its  effectiveness. 

Concept 

prototyping 

_  Operational 

Requirements  ^ ^  concepts  study 

capture 

Tender 
assessment 


Trade-off 
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Design  N.  y  Training 

review 

System  Operational 
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Figure  2:  The  Virtual  Ship  will  support  platform  ownership  through  all  phases  of  the 
lifecycle. 
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It  is  evident  that  the  Virtual  Ship  will  be  a  central  component  supporting  all  phases 
of  the  platform  lifecycle.  Figure  2  illustrates  this  concept. 

There  are  two  essential  components  of  SB  A.  One  aspect  is  a  common  tedmical 
framework  for  modelling  and  simulation,  and  this  consists  of  the  High  Level 
Architecture  (HLA),  the  Conceptual  Model  of  the  Mission  Spaced  (CMMS)  paradigm 
and  various  data  standardisation  activities.  The  second  key  aspect  is  the  way  that 
acquisition  business  is  conducted. 

The  common  technical  framework  provides  the  infrastructure  for  bringing 
individual  simulations  together  to  create  a  common  virtual  world.  The  HLA 
facilitates  the  linking  of  individual  simulation  models  over  a  network  and  the 
exchange  of  information  amongst  them  in  a  manner  that  facilitates  common 
interpretation  of  it.  The  HLA  is  described  in  detail  in  section  6. 

The  CMMS  paradigm  provides  a  process  for  abstracting  the  essential  elements 
required  of  the  virtual,  or  synthetic,  environment  in  order  to  guide  their  construction. 
Essential  components  are  identification  of  the  essential  entities,  their  intrinsic 
behaviours  and  the  interactions  amongst  them.  The  CMMS  will  provide  a  way  of 
thinking  about  the  virtual  environment  that  is  relevant  both  to  warfighters  and 
simulation  developers.  It  wiU  provide  a  common  reference  frame  through  which  the 
requirements  of  the  military  user  may  be  translated  into  a  form  that  is  the 
appropriate  basis  for  development  of  a  virtual  environment. 

The  data  standardisation  activities  particularly  concern  environmental  data  required 
to  compute  sensor  and  platform  performance,  and  the  visual  data  essential  m 
creation  of  reahstic  virtual  representations  of  the  real  world. 

The  new  acquisition  process  is  centred  on  the  Integrated  Product  Team  (IPT).  These 
teams  are  composed  of  aU  stakeholders  in  the  acquisition  and  include  cost  analysts, 
war  fighters,  designers,  suppliers  and  manufacturers,  testers  and  logisticians.  The 
broad  membership  of  these  teams  wiU  enable  them  to  better  consider  all  issues 
relevant  to  ownership  of  the  platform/ system  throughout  its  whole  Ufe.  These  teams 
will  be  supported  in  their  analysis  by  modelling  and  simulation.  Solutions  to 
requirements  will  be  provided  in  virtual  form  and  assembled  into  a  virtual  prototj^e 
of  title  whole  system.  The  common  technical  framework  for  modelling  and  simulation 
will  facilitate  this.  As  this  process  evolves  the  customer  and  supplier  will  acquire 
complete  validated  knowledge  of  the  model  upon  which  to  make  rninimal  risk 
decisions  in  proceeding  to  production. 

In  order  to  contribute  to  this  new  paradigm  for  acquisition,  the  key  technical 
challenge  is  to  establish  the  common  technical  framework  within  DSTO  and  Defence 
Industry.  In  addition,  there  will  be  a  requirement  to  contribute  models  that 
encapsulate  information  and  data  that  is  held  by  the  Commonwealth  and  which  will 
make  an  essential  contribution  to  tender  assessment.  Finally,  there  wiU  be  a 
requirement  for  advice  on  the  conduct  of  technical  assessments.  The  existence  of 
virtual  prototypes,  that  allow  solutions  to  be  exercised  by  humans  in  realistic 
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environments  and  scenarios,  will  require  new  methodologies  for  measuring 
effectiveness.  The  technical  community  will  drive  this  process. 

The  Virtual  Ship  has  significant  potential  to  contribute  to  an  evolution  of  acquisition 
practice  in  the  maritime  domain.  The  core  technology  being  adopted  by  the  Virtual 
Ship  project  is  the  High  Level  Architecture.  The  Virtual  Ship  project  wiU  facilitate 
adoption  of  this  core  component  of  the  US  common  technical  framework  by 
Australian  Defence  Industry.  The  Virtual  Ship  project  will  establish  the  specific 
technical  requirements  for  this  to  be  applied  to  maritime  simulation  and  hence 
acquisition.  The  Virtual  Ship  project  wih  develop  methodologies  for  exploiting  the 
capability  to  comprehensively  simulate  warship  operations  and  particularly 
measuring  effectiveness.  In  collaboration  with  the  acquisition  community,  the  Virtual 
Ship  project  will  be  able  to  provide  guidance  as  to  how  the  acquisition  process  might 
exploit  the  Virtual  Ship  to  enhance  platform  effectiveness,  reduce  tiie  risks  associated 
with  acquisition  and  ownership,  and  reduce  the  total  cost  of  ownership. 

The  Virtual  Ship  might  be  used  in  support  of  an  acquisition  as  follows.  Suppose  an 
operational  need  above  diat  satisfied  by  existing  capabilities  is  identified.  The 
existence  of  a  collection  of  system  models  will  be  brought  together  in  order  to 
explore  concepts  for  a  platform  that  provides  the  solution  to  the  requirement.  The 
particxilar  advantage  that  a  Virtual  Ship  capability  wiU  offer  is  that  of  immersing  the 
war  fighter  in  the  virtual  environment.  Apart  from  traditional  analysis  and 
compilation  of  numerical  measures  of  effectiveness,  this  wUl  enable  human 
interaction  characteristics  to  be  assessed. 

As  concepts  are  explored  the  formal  requirement  for  the  platform  will  evolve.  The 
constituent  models  of  the  Virtual  Ship  wUl  be  those  that  represent  existing  or 
prototype  systems.  For  example,  models  of  concept  radar  systems  may  be 
incorporated  and  the  operational  performance  compared  with  that  provided  by 
current  systems.  These  assessments  wiU  be  made  by  exercising  the  Virtual  Ship  in 
operationaUy  relevant  scenarios.  A  key  contribution  that  DSTO  wiU  make  in  this 
regard  is  through  provision  of  an  appropriate  threat  scenario  that  exhibits  the  true 
performance  of  threat  weapons  and  platforms. 

It  is  apparent  that  the  processes  of  capturing  requirements  and  demonstrating 
potential  solutions  (tender  assessment)  wiU  become  enmeshed  and  less  distinct.  This 
wUl  require  new  processes  for  acquisition  and  a  detailed  discussion  of  this  is  beyond 
the  scope  of  this  report.  However,  the  use  of  virtual  prototypes  wdU  ensure  that  when 
the  decision  is  made  to  proceed  to  construct  the  platform  many  risks  will  have  been 
identified  and  rriinirnised  and  maximum  mature  technology  insertion  will  be 
achieved. 

The  existence  of  a  Virtual  Ship  will  enable  the  platform  to  continuaUy  evolve  in 
virtual  form.  This  wiU  consist  of  replacement  of  system  models  as  new  ones  become 
available  which  demonstrate  enhanced  capability.  Essentially,  at  all  stages 
throughout  the  life  of  the  platform,  a  Virtual  Ship  may  exist  that  differs  from  the 
actual  platform  in  that  it  represents  the  capability  if  the  most  recent  technology  were 
exploited.  It  may  be  considered  that  the  existence  of  a  Virtual  Ship  will  enable  the 
creation  of  a  living  design  that  evolves  with  technology.  At  given  points  in  time  this 
win  enable  upgrades  of  the  physical  platform  to  take  place  seamlessly,  and  prevent 
the  obsolescence  of  platforms  required  in  service. 
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To  fuUy  exploit  the  Virtual  Ship  in  support  of  platform  ownership  at  aU  stages  of  the 
lifecycle  requires  adoption  of  the  concept  by  aU  stakeholders.  In  the  context  of 
acquisition,  the  process  must  evolve  to  exploit  the  distinctive  capability  of  a  virtual 
platform  to  visualise  solutions  to  requirements  and  exercise  them  in  operationally 
relevant  scenarios.  This  process  must  proceed  in  partnership  with  development  of 
the  technical  framework  that  enables  it.  This  wiU  allow  all  opporturaties  for 
exploitation  to  be  identified  and  will  ensure  that  technical  activities  address  the  array 
of  commercial  issues  that  confront  acquisition  organisations.  In  addition  to  the 
partnership  required  between  the  acquisition  and  technical  communities  is  a 
partnership  with  Industry.  The  technical  aspects  of  this  relationship  are  discussed  m 
the  context  of  the  Virtual  Ship  in  section  7. 


6.  Architecture 


6.1  General  Requirements  for  the  Virtual  Ship  Architecture 

The  Virtual  Ship  Architecture  will  provide  the  framework  enabling  system  models  to 
be  brought  together  to  simulate  warship  operations.  To  achieve  this  the  Virtual  Ship 
Architecture  requires  a  number  of  features.  It  must  have  a  modular  structure  in  order 
that  components  can  be  reused  and  applied  across  a  range  of  applications.  The 
architecture  must  be  open  so  that  the  capabiHties  of  many  participants  may  be 
utilised  The  architecture  must  support  integration  of  models  of  varying  degrees  of 
fideUty,  which  wiU  be  mapped  to  appUcations.  The  architecture  must  support  use  of 
models  both  for  analysis  and  for  real  time  human-in-the-loop  applications.  Models 
used  for  analysis  will  typicaUy  be  nm  many  times  in  order  to  compile  statisticaUy 
relevant  measures  of  effectiveness.  Their  essential  characteristics  are  execution  speed 
constrained  only  by  computer  processor  power,  and  repeatability  under 
circumstances  of  identical  initial  conditions  and  inputs. 


The  Virtual  Ship  architecture  must  support  a  degree  of  hardware  heterogeneity.  For 
example  it  is  appropriate  that  simulations  may  be  hosted  on  PCs  or  workstations 
running  various  versions  of  the  UNIX  operating  system.  The  architecture  should  also 
support  simulations  constructed  in  a  variety  of  programming  languages.  The 
imderlying  architecture  should  be  supportable  into  the  future  and  have  scope  to 
accommodate  models  obtained  from  other  nations  through  various  exchange 
mechanisms.  The  Virtual  Ship  Architecture  is  also  required  to  support  distributed 
simulation.  When  a  mature  capabihty  exists  to  comprehensively  simulate  warship 
operations  it  will  be  possible  to  exercise  together  multiple  instances  of  the  Virtual 
Ship.  The  scope  also  exists  to  exercise  the  Virtual  Ship  with  and  against  similar 
virtual  platforms  tmder  development  in  other  nations,  or  those  developed  in  the  air 
and  land  domains. 

6.2  The  High  Level  Architecture  -  HL A 

In  consideration  of  these  factors,  and  particularly  trends  in  modelling  and  simulation 
in  the  US,  it  is  appropriate  to  exploit  Ae  High  Level  Architecture^^  (HLA)  as  the  basis 
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for  the  Virtual  Ship  Architecture.  The  essence  of  the  HLA  is  as  follows.  The  HLA 
supports  distributed  simulation  and  supersedes  both  the  DIS  protocol  and  the 
Aggregate  Level  Simulation  Protocol  (ALSP).  It  facilitates  the  connection  of 
simulations  over  some  network  and  provides  the  mechanisms  by  which  they 
exchange  information  about  the  entities  they  model,  send  and  receive  interactions 
and  co-ordinate  their  time  advance.  In  the  terminology  of  the  HLA,  individual 
simulation  models  are  known  as  federates.  The  collection  of  federates  brought 
together  to  simulate  a  complex  environment  is  known  as  a  federation.  It  is  through 
the  common  interpretation  of  shared  data  that  the  federates  interact  within  a  single 
virtual  environment. 

There  are  three  components  of  the  HLA.  These  are  the  rules^^,  the  Object  Model 
Template!^  (OMT)  and  the  interface  specification^^.  The  rules  mandate  certain 
characteristics  of  models  brought  together  under  the  HLA.  The  key  ol^ective  in 
mandating  certain  characteristics  in  rules  is  to  ensure  that  models  are  re-useable 
across  applications. 

The  data  exchanged  by  the  federates  are  arranged  in  an  object  model  and  classified 
according  to  whether  the  data  describe  persistent  entities  or  transient  events. 
Persistent  entities  are  known  as  objects  and  each  is  described  by  a  set  of  attributes. 
Transient  events  are  known  as  interactions  and  are  described  by  a  set  of  parameters. 
The  format  of  this  object  model  is  given  by  the  OMT.  Each  federate  is  described  by  a 
Simulation  Object  Model  (SOM)  which  is  constructed  in  the  format  of  the  OMT.  The 
SOM  details  the  object  attributes  that  this  federate  either  provides  or  receives 
information  about.  It  also  details  the  interactions  that  this  federate  initiates  or 
receives. 

AU  the  data  exchanged  amongst  the  collection  of  federates  is  described  by  the 
Federation  Object  Model  (FOM).  The  FOM  describes  aU  objects  within  the  federation 
and  aU  attributes  that  describe  them.  It  also  describes  all  interactions  that  occur 
within  tile  federation.  The  FOM  is  essentially  a  superset  of  tiie  SOM's  and  is 
constructed  according  to  the  OMT.  It  can  be  viewed  as  the  data  exchange  contract 
amongst  federates.  If  the  FOM  is  considered  as  a  standard  for  a  particular  simulation 
application  then  aU  models  engineered  to  this  standard  will  have  the  necessary  basic 
functionality  to  operate  together. 

The  HLA  interface  specification  describes  the  means  by  which  federates  interact  with 
the  underlying  data  transport  mechanism,  known  as  the  Run  Time  Infrastructure 
(RTI).  The  RTI  provides  six  service  sets.  These  enable  management  of  the  federation, 
the  exchange  of  data  amongst  the  federates  and  the  co-ordination  of  their  time. 

The  federates  exchange  information  via  the  RTI  through  the  processes  of  publication 
and  subscription.  Federates  that  own  object  attributes  publish  updates  of  their 
values.  Federates  that  wish  to  receive  attribute  updates  subscribe  to  these  attributes. 
Hence,  when  a  federate  publishes  a  new  value  of  an  attribute  this  is  passed  by  the 
RTI  to  all  other  federates  than  have  subscribed  to  this  attribute.  Federates  also 
publish  and  subscribe  interactions. 
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As  described  above,  the  publication  and  subscription  functions  exploit  two  sets  of 
services  provided  by  the  RTI.  These  are  the  declaration  management  and  object 
management  services.  The  full  collection  of  services  is  as  follows: 

Federation  management. 

Declaration  management. 

Object  management. 

Ownership  management. 

Time  management. 

Data  distribution  iimnagement. 

The  federation  management  services  provide  the  means  to  create  and  destroy 
federation  executions,  pause  and  restart  federation  executions,  save  the  state  of  a 
federation  and  restore  a  saved  state. 

The  declaration  management  services  provide  the  means  by  which  federates  advise 
the  RTI  as  to  which  ol^ect  attributes  Ihey  wish  to  publish  and  subscribe  to,  and 
similarly  with  respect  to  interactions. 

The  object  management  services  provide  the  means  by  which  federates  send  and 
receive  attribute  updates,  send  and  receive  interactions  and  alter  the  transportation 
and  ordering  properties  of  these  updates. 

The  ownership  management  services  provide  the  means  by  which  ownership  of 
attributes  may  be  transferred  amongst  the  federates.  This  provides  a  very  powerful 
capability.  A  federate  that  owns  an  attribute  has  responsibility  for  providing  updates 
of  it.  The  ownership  management  services  provide  the  means  by  which  this 
resporisibility  is  vested  in  Ae  most  capable  federate.  A  consequence  is  that  a  single 
physical  object  represented  within  a  federate,  such  a  ship,  may  have  ownership  of  its 
attributes  distributed  amongst  a  munber  of  federates. 

The  time  management  services  provide  the  means  by  which  federates  advance  their 
time,  and  particularly  the  means  by  which  they  co-ordinate  their  time  advances. 
These  services  support  both  DIS-like  and  ALSP-type  time  management  approaches. 
In  DIS  there  is  no  common  time  and  each  of  the  federates  advances  its  time  according 
to  a  local  clock.  In  ALSP-type  federations  the  federates  must  co-ordinate  their  time 
advances  and  particularly  preserve  causality  through  delivery  of  messages  in  time 
stamp  order. 

The  data  distribution  services  provide  the  means  by  which  routing  spaces  may  be 
created  in  order  to  more  efficiently  transport  attribute  updates  and  interactions  over 
the  network. 

The  software  that  implements  the  interface  specification  is  also  referred  to  as  the  RTI 
and  the  application  developer  makes  use  of  it  through  the  Application  Programmers 
Interface  (API).  DMSO  has  sponsored  development  of  an  RTI  and  API's  are  currently 
available  in  C++,  Ada  95,  CORBA IDL  and  JAVA.  There  are  two  parts  of  the  interface 
to  the  RTI.  These  are  the  RTI  Ambassador  and  the  Federate  Ambassador.  The  RTI 
Ambassador  is  a  library  that  is  linked  into  each  federate  and  facilitates 
communication  from  the  federate  to  the  RTI.  The  Federate  Ambassador  facilitates 
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conunxmication  from  the  RTI  to  the  federate.  Although  the  interface  to  the  Federate 
Ambassador  is  mandated,  the  simulation  developer  must  construct  the  internal 
details  in  order  to  implement  the  appropriate  response  to  messages  from  the  RTI.  As 
an  example,  when  a  federate  is  required  to  issue  an  attnbute  update  this  is  a(^eved 
through  a  call  to  an  RTI  Ambassador  procedure.  When  this  attribute  update  is 
received  at  another  federate,  the  RTI  Ambassador  at  this  federate  makes  a  caU-back 
to  the  appropriate  Federate  Ambassador  procedure. 


Figure  3:  A  junctional  view  of  the  HLA.  Many  different  types  of  federates  may  operate 
together  over  a  network.  The  RTI  provides  the  services  that  facilitate  transfer  of 
data  amongst  federates  and  the  co-ordination  of  their  time  advances. 

A  functional  view  of  the  HLA  is  shown  in  Figure  3.  A  number  of  federates  may  be 
brought  together  to  create  a  common  virtual,  or  synthetic,  enviroiunent.  Some  of 
these  may  be  passive,  such  as  data  loggers  and  stealth  viewers.  These  merely  receive 
data  transmitted  over  the  network  and  analyse  or  visualise  it.  The  HLA  enables 
event-stepped  and  time-stepped  federates  to  operate  together  and  co-ordinates  then 
time  advances.  Real  time  simulations  may  participate  in  the  federation,  as  may  real 
equipment  through  an  appropriate  interface.  Engineering  simulations,  usually  based 
upon  the  laws  of  physics,  may  also  be  integrated  into  the  federation  execution.  It  is 
this  capability  that  will  enable  computer  aided  design  tools  to  be  an  integral  part  of 
the  Virtual  Ship. 

It  is  appropriate  to  make  comment  concerning  those  aspects  of  the  HLA  that  make  it 
the  appropriate  basis  for  the  Virtual  Ship  Architecture.  The  FOM  is  used  to  configure 
the  RTI  to  facilitate  data  exchange  in  accordance  with  it.  Thus  the  federation 
developer  may  determine  the  data  exchange  format  through  design  of  the  FOM.  This 
offers  considerable  flexibility  in  optimising  the  data  exchange  for  the  application  at 
hand. 

The  HLA  has  been  declared  as  the  standard  for  distributed  simulation  in  the  US. 
Indeed,  as  of  FYOl  any  non-HLA  compliant  simulations  will  be  retired  from  use 
unless  an  exemption  is  grantediL  In  addition  NATO  has  recently  proposed  HLA  as 
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the  technical  standard  for  distributed  simulation^’'.  There  are  two  consequences  of 
this.  A  great  deal  of  effort  is  being  expended  in  the  US  and  elsewhere  on 
development  of  tools  that  support  distributed  simulation  under  the  HLA.  These 
include  object  model  development  tools,  standard  libraries  and  lexicons,  data 
standards  and  automatic  code  development  tools.  The  availability  of  these  will 
enhance  simulation  developers  capacity  to  produce  HLA  compliant  federates.  The 
second  consequence  is  that  any  models  obtained  from  the  US,  and  potentially  other 
nations,  wiU  be  HLA  compliant  and  therefore  more  easily  integrated  into  a  Virtual 
Ship  environment  based  on  the  HLA. 

The  HLA  services  offer  considerable  advantages  compared  with  other  distributed 
simulation  technologies.  The  exchange  of  data,  whether  this  be  through  attribute 
updates  or  interactions,  is  facilitated  through  processes  of  subscription  and 
publication.  Federates  publish  the  attributes  of  the  objects  they  own,  and  only 
provide  updates  of  these  when  they  change.  This  contrasts  with  the  DIS  where 
protocol  data  units  (PDU's)  are  transmitted  over  the  network  which  contain 
mandated  data  components,  irrespective  of  whether  the  data  has  changed  or  not 
since  it  was  last  transmitted.  Similarly,  federates  subscribe  to  only  the  data  they 
require.  This  approach  has  the  potential  to  reduce  network  bandwidth  requirements 
and  enhance  the  scalabdity  of  federations. 

A  most  powerful  aspect  of  the  HLA  is  its  time  management  service  set  and  the  ability 
it  offers  to  bring  together  simulations  that  advance  time  in  different  ways.  HLA 
supports  real  time  applications,  such  as  those  that  derive  from  the  DIS  community. 
These  federates  typically  advance  their  time  according  to  a  local  clock  and 
interactions  and  attribute  updates  occur  when  the  relevant  packets  of  data  are 
received,  or  at  a  time  attached  to  them.  HLA  also  supports  federates  that  require 
delivery  of  messages  in  time  stamp  order  and  require  co-ordinated  time  advance. 
These  applications  are  typically  used  in  analysis  applications  and  are  often  run  many 
times  in  order  to  compile  statistically  relevant  measures  of  effectiveness.  An  essential 
requirement  for  these  models  is  that  causality  is  strictly  preserved  and  that 
simulation  runs  are  reproducible  when  provided  with  the  same  initial  conditions  and 
inputs  throughout  execution.  HLA  supports  delivery  of  messages  in  time  stamp 
order  and  provides  mechanisms  through  which  the  time  advance  of  federates  may 
be  coordinated.  It  provides  mechanisms  by  which  time  stepped,  event  stepped  and 
real  time  federates  may  operate  together  and  coordinate  their  time  advances. 

The  ownership  management  services  provide  the  means  by  which  the  responsibility 
to  update  attributes,  otherwise  referred  to  as  the  ownership  of  attributes,  may  be 
exchanged  amongst  federates.  This  capability  may  be  exploited  in  a  mrniber  of  ways. 
The  ownership  of  objects  and  attributes  may  be  transferred  amongst  a  number  of 
federates  in  order  to  distribute  the  computational  load.  The  ownership  of  attributes 
may  be  transferred  to  specialised  federates  in  order  to  provide  a  higher  fidelity 
representation.  An  example  of  this  is  the  radar  cross  section  of  an  entity.  This  may  be 
simply  described  by  a  single  number.  However,  it  may  be  desired  to  use  a  high 
fidelity  model  that  determines  the  cross  section  as  a  fimction  of  the  aspect  of  the 
entity.  A  dedicated  model  may  provide  such  a  capability  and  ownership  of  tiiis 
attribute  will  therefore  be  transferred  to  it.  Another  notable  application  of  this 
capability  is  in  modelling  short  time  scale  interactions.  An  example  is  the  end  game 
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encounter  between  an  anti-ship  missile  and  a  ship.  The  circumstance  may  arise  that 
network  latency  prevents  the  timely  exchange  of  data  between  the  federates 
representing  the  ship  and  missile  and  therefore  renders  the  simidation  xmrealistic.  A 
potential  solution  is  to  transfer  ownership  of  the  missile  to  the  federate  modeUing  tilae 
ship  so  that  the  encoxmter  is  modelled  within  a  single  federate. 

A  final  distinctive  capability  offered  by  the  HLA  is  through  its  data  distribution 
management  services.  This  enables  the  definition  of  regions  of  interest,  within  which 
federates  may  express  the  desire  to  receive  certain  data.  An  example  of  this  is  a 
geographic  region  of  interest.  If  a  federate  models  a  ship  and  the  sonars  on  board,  as 
far  as  modeUing  these  is  concerned  it  may  be  deemed  that  the  federate  requires  data 
concerning  other  entities  within  a  30km  radius  of  it,  say.  A  region  of  interest  aroimd 
the  ship  may  be  defined  and  the  federate  modeUing  the  ship  wiU  oiUy  receive  data 
concerning  other  entities  within  this  region.  This  service  therefore  provides  an 
additional  means  by  which  network  traffic  is  reduced.  The  definition  of  regions  of 
interest  for  data  distribution  may  more  generaUy  used  to  impose  a  filter  on  the 
deUvery  of  data  to  certain  federates. 

6.3  Elements  of  the  Virtual  Ship  Architecture 

The  Virtual  Ship  wUl  be  constructed  in  accordance  with  the  High  Level  Architecture. 
In  addition,  the  specific  objective  of  simulating  warship  operations  necessitates 
addition  to,  or  specialisation  of,  the  HLA.  This  coUection  of  additions  and 
specialisations  wUl  constitute  the  Virtual  Ship  Architecture  (VSA). 

There  wiU  be  five  essential  elements  of  the  VSA.  These  are  described  as  foUows. 

The  Virtual  Ship  Federation  Object  Model  -  VS-FOM 

The  VS-FOM  wiU  define  the  data  exchange  standard  for  those  federates  that 
constitute  the  Virtual  Ship.  It  wUl  be  constructed  in  accordance  with  liie  Object 
Model  Template  (OMT).  The  VS-FOM  wiU  exploit  class  hierarchies  in  order  to 
support  federates  of  differing  fideUty.  The  VS-FOM  wUl  be  constructed  in  such  a 
manner  that  it  readUy  enables  the  incorporation  of  additional  object  and  interaction 
classes. 

The  Virtual  Ship  Lexicon 

The  objects,  attributes,  interactions  and  parameters  within  the  VS-FOM  wiU  form  the 
Virtual  Ship  lexicon.  The  lexicon  wiU  provide  for  common  terminology  use  across 
modeUing  appUcations.  It  is  through  the  common  interpretation  of  data  that  a 
common  world  view  can  be  estabUshed  amongst  distributed  federates. 

The  Virtual  Ship  Rules 

The  Virtual  Ship  rules  wUl  describe  mandatory  characteristics  of  federates  brought 
into  the  Virtual  Ship,  over  and  above  the  HLA  rules. 
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Virtual  Ship  Data  Standards 

Different  modelling  applications  relevant  to  the  Virtual  Ship  have  shared  interest  in 
data.  The  provision  and  exploitation  of  tihis  data  will  be  facilitated  through 
establishment  of  common  data  standards. 

The  Virtual  Ship  Tools 

A  variety  of  existing  tools  wiU  support  development  of  the  Virtual  Ship.  In  addition 
to  tools  that  support  the  HLA  generally,  a  requirement  for  additional  tools  can  be 
foreseen.  These  will  support  federate  development,  object  model  consistency 
checking,  federate  monitoring  including  stealth  viewing  and  federation  execution 
management  and  analysis. 

6.4  Aspects  Related  to  the  Architecture 

The  architecture  of  the  Virtual  Ship  is  independent  of  its  implementation.  However  it 
is  only  through  implementation  of  the  Virtual  Ship  concept  that  applications  may  be 
addressed  and  benefit  derived.  To  this  end  a  range  of  additional  issues  must  be 
explored  and  some  of  these  are  detailed  in  the  following. 

Software 

A  nximber  of  software  components  will  be  utilised  in  construction  of  the  Virtual  Ship. 
The  HLA  RTI  will  provide  the  underl5dng  mechanism  for  data  exchange  amongst 
models.  Initially  it  is  appropriate  to  exploit  that  provided  by  DMSO.  As  time  passes 
commercial  implementations  of  the  RTI  will  become  available.  It  is  anticipated  that 
what  wiU  differentiate  one  RTI  form  another  will  be  the  type  of  simulation 
application  for  which  its  performance  is  optimised.  For  example,  some  RTFs  may  be 
optimised  for  DlS-hke  real  time  operation!®  whereas  others  may  be  optimised  for 
analysis  t5qje  operations.  Given  that  the  HLA  interface  is  mandated,  there  will  be  no 
technical  implications  in  moving  from  one  RTI  to  another,  apart  from  recompilation 
of  federates. 

The  language  in  which  federates  are  developed  is  essentially  irrelevant,  as  long  as  a 
mechanism  is  available  by  which  the  federate  may  invoke  the  RTI  API.  At  present 
APTs  are  available  in  C++,  JAVA,  CORBA IDL  and  ADA  95.  It  is  anticipated  that 
most  federates  will  be  constructed  in  these  languages  or  wrapped  in  them.  A 
particular  challenge  will  be  to  bring  legacy  simulations  to  compliance  with  the 
Virtual  Ship  Architecture.  A  class  of  these  is  physics  based  models  typically  written 
in  FORTRAN.  A  variety  of  novel  techniques  will  be  required  to  construct  wrappers 
that  implement  a  distributed  smudation  capability. 

Hardware 

As  with  software  it  is  intended  to  support  simulation  implementatioi\s  on  a  range  of 
common  computational  platforms.  This  particularly  includes  PC's  and  workstations 
nmning  varieties  of  the  UNIX  operating  system.  The  availability  of  RTI  software  for 
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a  range  of  platforms  will  facilitate  this.  The  DMSO  RTI  currently  supports  the 
following  hardware:  SGI,  HP,  Sun,  PC  (Windows  NT),  DEC  Alpha. 

Security 

It  is  intended  that  the  Virtual  Ship  Architecture,  and  partictdarly  the  VS-FOM  and 
Virtual  Ship  lexicon,  will  be  unclassified.  The  models  and  data  required  to  instantiate 
the  Virtual  Ship  will  be  classified  by  the  model  and  data  owner.  The  classification  of 
particular  instantiations  of  the  Virtual  Ship  will  be  determined  by  the  highest 
classification  of  constituent  parts.  In  general,  it  is  anticipated  that  classified 
instantiations  will  exist  in  a  secure  environment.  In  the  event  that  classified 
components  are  remote,  encryption  of  network  traffic  wiH  be  required.  The  impact  of 
this  on  the  performance  of  distributed  simulation  is  not  fuUy  known  and  will  be  a 
subject  for  investigation. 

Software  development  standards 

It  wai  be  required  to  adopt  a  standard  for  software  development  in  the  Virtual  Ship 
project.  The  objective  of  adopting  a  standard  is  to  ensture  that  models  have  been 
correctly  implemented,  to  provide  a  functional  description  of  components  to  other 
participants  in  the  Virtual  Ship  and  to  enable  rapid  integration  through  the 
availability  of  appropriate  documentation. 

It  is  anticipated  that,  as  a  minimum,  software  components  will  be  supported  by  a 
fimctional  specification,  a  detailed  design  document  and  a  user  guide.  A  test 
specification  and  record  of  testing  should  also  be  available.  It  may  be  required  to 
waive  some  of  these  requirements  in  the  case  of  legacy  code,  however  this  is 
expected  to  be  an  extreme  circumstance. 

In  order  to  facilitate  rapid  integration  and  re-use  it  is  anticipated  that  software  will 
be  modular  and  may  adhere  to  an  object-oriented  methodology,  although  these 
requirements  are  recommendations  only.  The  development  of  class  libraries  may 
contribute  to  re-use.  This  may  be  particularly  so  in  the  area  of  HCI  displays. 

As  die  Virtual  Ship  concept  evolves,  detailed  recommendations  concerning  software 
development  standards  will  be  developed  and  promulgated. 

Configuration  control 

All  components  of  the  Virtual  Ship  shall  be  subject  to  change  control.  This  includes 
the  constituent  models,  the  architecture,  requisite  data  and  federations. 

With  development  of  the  architecture,  a  baseline  standard  will  be  designated  as 
Version  1.  Change  control  will  be  mandatory  after  declaration  of  this  baseline. 
Change  control  of  individual  federates  wiU  be  the  responsibility  of  the  federate 
custo^an.  Details  of  federate  version  numbers  will  be  an  essential  component  of 
federation  change  control,  and  will  be  a  requirement  for  participation  in  an  execution 
of  the  Virtual  Ship  federation. 
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7.  Data 

The  exchange  and  common  interpretation  of  data  is  the  fotmdation  of  distributed 
simtdation.  Witiiin  the  High  Level  Architecture  the  data  exchanged  is  structured 
using  the  Object  Model  Template  and  the  content  standardised  through  use  of  a 
conunon  lexicon.  Development  of  the  Virtual  Ship  Architecture  will  establish  a 
lexicon  for  use  in  simidating  warship  operations.  More  generally,  the  Object  Model 
Data  Dictionaryi^  developed  by  DMSO  is  an  attempt  to  provide  a  common  lexicon 
for  use  in  distributed  simulation  applications. 

A  number  of  other  issues  pertaining  to  data  are  raised  in  this  section.  There  is  a 
requirement  for  common  access  to  authoritative  data  sources  in  order  to  establish  a 
rpahstir  common  world  view.  There  is  a  requirement  to  identify  common  data 
requirements  across  apphcations  and  standardise  these.  The  avaUability  of 
experimental  and  trials  data  is  essential  for  model  validation.  This  is  a  critical 
exercise  in  order  to  establish  the  credibility  of  the  Virtual  Ship  as  a  tool  for  exploring 
a  wide  variety  of  issues  in  maritime  operations.  Finally,  large  quantities  of  data  may 
be  gathered  during  federation  executions.  This  offers  considerable  scope  for 
replaying  virtual  exercises  to  support  training,  mission  rehearsal  and  tactical 
development.  Analysis  fxmctions  may  be  embedded  within  the  federation  and  the 
quantity  of  data  available  poses  a  considerable  challenge  in  optimising  the  analysis 
methodology. 

7.1  Common  Access  to  Authoritative  Data  Sources 

In  addition  to  exchanging  data,  distributed  simulation  applications  have  a 
requirement  to  access  large  bodies  of  data  that  describe  the  physical  environment. 
These  data  may  permit  computation  of  soimd  and  electromagnetic  propagation,  or 
they  may  enable  the  creation  of  a  highly  realistic  visual  representation  of  a  scenario. 
Although  such  data  could  conceivably  be  exchanged  amongst  federates,  the  sheer 
volume  of  it  precludes  this  on  practical  grounds.  The  appropriate  solution  is  for 
individual  federates  to  access  Ae  data  directly,  with  conunonahty  of  use  achieved 
through  a  shared  reference  to  the  data. 

Particular  initiatives  concerned  with  facilitating  common  access  to  authoritative  data 
sources  are  the  Master  Environment  Library^o  (MEL)  and  Synthetic  Environment 
Data  Representation  and  Interchange  Specification^^  (SEDMS)  projects.  These  are 
core  components  of  the  common  technical  framework  for  modelling  and  simulation 
being  pursued  by  DlvGO.  Both  may  be  exploited  in  establishing  and  using  the 
Virtual  Ship. 

The  MEL  is  an  online  catalogue  of  environmental  data  sources.  A  user  may  identify 
data  that  satisfies  a  requirement  and  order  the  data  online.  It  provides  a  single  point 
through  which  users  may  access  a  large  collection  of  authoritative  data  sources. 
SEDRIS  is  concerned  with  defining  a  standard  data  format  for  environmental  data  as 
used  in  synthetic  environments.  Its  scope  includes  both  visual  data  and  data  required 


http:  /  /  s3.arlut.utexas.edu  /  omdds  /  code  /  index.htm 
http:  /  /  mel.dmso.mil 
21  http:  /  /  www.sedris.org 
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to  determine  propagation  of  soxmd  and  electromagnetic  radiation.  A  number  of 
API's  are  being  developed  for  converting  between  the  SEDRIS  format  and 
proprietary  data  formats. 

In  addition  to  exploiting  these  US  initiatives,  there  will  be  a  requirement  to 
determine  authoritative  sources  of  data  to  support  the  Virtual  Ship.  These  data  will 
describe  sensors,  weapons  and  O  systems.  It  will  be  required  to  establish  the  means 
of  access  to  relevant  data,  along  with  the  responsibility  for  accuracy  and 
management  of  data  components. 

7.2  Identification  and  Standardisation  of  Common  Data 
Requirements 

There  are  many  mature  applications  of  modelling  and  simulation  in  the  maritime 
domain.  These  have  traditionally  operated  independently  of  one  another  and  the 
challenge  is  to  bring  them  together  in  the  Virtual  Ship  project.  As  tins  process  occurs 
it  is  anticipated  that  common  requirements  for  data  will  be  identified.  This  process 
wiU  drive  the  establishment  of  data  standards  so  that  additional  sources  of 
authoritative  data  may  be  made  available. 

A  typical  area  in  which  common  data  is  required  concerns  the  platform  itself.  A 
sig^cant  capability  exists  to  model  the  hydrodynamics  of  warships  and  this 
requires  detailed  information  concerning  the  hull  shape  and  distribution  of  mass  in 
the  vessel.  Another  weU  developed  area  is  that  of  damage  modelling.  These  models 
require  detailed  descriptions  of  the  vessel  construction,  including  the  layout  and 
connectivity  of  compartments  and  the  distribution  of  equipment  throughout  the 
vessel.  The  requirement  for  vessel  construction  data  is  common,  yet  different  sources 
are  used  for  each  application.  There  is  clear  scope  for  developing  a  common  format 
for  the  required  data. 

The  development  of  data  standards  will  provide  considerable  benefits  beyond 
economising  the  effort  in  data  collection.  Aspects  of  future  concepts  for  platforms 
may  be  specified  in  terms  of  standard  data  formats.  This  will  enable  the  suite  of 
simulatioris  that  constitute  the  Virtual  Ship  to  be  applied  to  investigate  a  range  of 
performance  issues  relating  to  the  new  platform.  During  an  acquisition,  potential 
suppliers  may  provide  data  concerning  their  solutions  in  standard  formats.  Again 
the  simulation  tools  of  the  Virtual  Ship  may  be  immediately  applied  in  order  to 
acquire  a  detailed  appreciation  of  the  capabilities  of  the  system  offered. 

7.3  Data  Required  to  Validate  Models 

The  Virtual  Ship  offers  the  capability  to  simulate  environments  and  circumstances 
beyond  those  that  can  be  achieved  in  exercises  and  trials.  In  order  that  these 
simulated  scenarios  are  credible  with  users  of  the  Virtual  Ship  it  is  essential  that  it  be 
validated  through  comparison  with  available  data.  As  a  consequence  of  this 
requirement  it  is  essential  that  vaUdation  data  is  gathered  and  archived.  At  a  low 
level  is  the  requirement  for  physics  based  experimental  data  with  which  models  of 
sensors  may  be  validated.  At  a  higher  level  is  a  requirement  for  data  concerning  the 
outcome  of  exercises  and  trials,  where  higher  order  performance  measures  are 
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recorded.  These  data  will  be  used  to  validate  instantiations  of  the  Virtual  Ship  and 
the  methodology  for  bringing  models  together. 

An  essential  requirement  during  the  acquisition  process  is  to  gather  data  to  validate 
models  developed  specifically  to  support  the  acquisition.  This  may  require  the 
construction  of  prototypes  or  subsystem  components.  The  intention  is  to  provide 
sufficient  data  so  that  a  required  degree  of  confidence  m  the  modelling  solution  is 
acquired. 

7.4  Data  Gathering  During  Federation  Execution 

The  conduct  of  sunxdation  offers  the  capability  to  embed  data  gathering  functions 
within  the  models.  In  the  context  of  a  distributed  simulation,  data  may  be  gathered 
within  individual  federates  and  may  also  be  gathered  from  the  network.  In  the  recent 
Synthetic  Theatre  of  War  (STOW)22  demonstration  in  October  1997  a  ntunber  of  tools 
were  developed  to  gadier  the  data  shared  amongst  a  collection  of  federates^s.  In 
particular,  the  Common  Data  Infrastructure  (CDI)  gathered  data  in  a  distributed 
fashion  and  stored  it  in  an  Oracle  database.  An  advantage  that  the  HLA  offers  in 
automated  collection  of  data  is  that  the  federation  execution  data  (FED)  file 
documents  the  object  and  interaction  class  hierarchies  and  may  be  used  to 
automatically  configure  the  database.  This  particular  application  of  embedded  data 
gathering  was  to  provide  a  post  exercise  replay  facility  in  support  of  a  computer 
aided  exercise.  The  term  after  action  review  (AAR)  is  also  used  to  describe  this 
process.  Te  capability  to  replay  virtual  exercises  will  make  a  critical  contribution  to 
training,  mission  rehearsal  and  tactical  development. 

It  is  evident  that  data  may  also  be  gathered  to  support  an  analysis  application  or 
decision  making  process.  Key  performance  measures,  such  as  detection  ranges,  may 
be  recorded.  In  addition,  records  of  events  internal  to  federates  may  be  compiled  and 
correlated  with  each  other  in  order  to  identify  dependencies  and  causalities.  It  is 
through  this  capability  to  embed  data  gathering  that  the  Virtual  Ship  will  provide 
maximum  utility  in  supporting  decision  making. 

A  difficidty  evident  in  performing  AAR  in  support  of  the  STOW  program  was  the 
extraction  of  meaningful  data  and  performance  measures  from  aU  the  data  gathered 
throughout  a  federation  execution.  This  difficulty  is  also  evident  in  the  context  of  the 
analysis  application.  The  challenge  is  to  embed  analysis  functions  within  the 
federation  so  that  analysis  is  performed  whilst  the  federation  execution  is  underway. 
The  objective  is  to  reduce  the  amount  of  data  collected  and  stored,  and  to  provide 
meaningful  data  in  a  timely  manner.  The  quantity  of  data  that  may  be  generated 
during  large  simrdation  executions  is  too  large  to  facilitate  rapid  analysis  after  the 
event. 


^  http:  /  /  stow98.spawar.naw.mil/ 

23  Kanewske,  C.  &  Fine,  S.  (1998)  STOW  systems  integration,  tools  and  applications.  Spring  1998  Simulation 
Interoperability  Workshop,  Orlando,  Florida.  Paper  98S-SIW-110.  Available  at 
http://siso.sc.ist.ucf.edu/siw/98Spring/view-papers.htm 
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8.  Industry  Participation 


Engaging  Industry  in  the  Virtual  Ship  program  is  an  essential  prerequisite  for  the 
concept  to  achieve  its  vision  of  supporting  platform  ownership  throughout  aU  phases 
of  the  lifecycle.  To  create  representations  of  the  force  in  being  requires  models  of 
existing  systems.  For  the  most  part,  these  are  appropriately  provided  by  the  system 
suppliers.  To  create  representations  of  future  platforms,  whether  dming  concept 
exploration  or  acquisition,  requires  models  of  future  systems.  Again  the  ideal 
solution  is  for  these  models  to  be  provided  by  Industry. 

A  principal  advantage  of  the  Virtual  Ship  concept  is  the  abihty  to  exercise  in  reahstic 
environments  against  realistic  threats.  The  creation  of  the  xmique  environments  and 
threat  scenarios  relevant  to  AustraHa's  strategic  circumstances  will  be  a  principal 
task  for  DSTO.  The  capability  is  therefore  required  to  effectively  integrate  models 
provided  by  Industry  with  models  provided  by  DSTO. 

There  are  a  number  of  requirements  in  creating  the  circumstances  whereby  Industry 
models  are  readily  integrated  within  the  Virtual  Ship.  Exploiting  the  HLA  imposes 
technical  demands.  In  addition.  Industry  must  be  confident  that  the  integration 
process  allows  the  performance  of  the  modelled  system  to  be  adequately 
demonstrated.  Industry  must  also  be  satisfied  that  bringing  simulations  into  the 
Virtual  Ship  federation  wiQ  not  compromise  their  Intellectual  Property  Rights  (IPR). 

The  solution  to  these  requirements  is  to  engage  Industry  in  development  of  the 
Virtual  Ship  Architecture  and  to  provide  a  high  degree  of  transparency  in  the  way 
the  Virtual  Ship  is  used. 

Engaging  Industry  in  development  of  the  Virtual  Ship  Architecture  will  ensure  drat 
the  Industry  perspective  is  accommodated  in  its  formulation.  It  will  also  ensure  that 
Industry  has  an  intimate  knowledge  of  the  VSA  and  is  therefore  able  to  engineer 
models  so  that  they  may  be  integrated  into  the  Virtual  Ship.  As  the  VSA  evolves  it 
wiU  be  exercised  using  simple  and  generic  models.  Industry  will  be  invited  to 
participate  in  these  demonstrations  in  order  that  they  may  acquire  practical 
experience  of  integrating  models  using  the  HLA. 

Use  of  die  HLA  and  a  standard  data  exchange  format  as  embodied  in  the  VS-FOM 
provides  a  mechanism  through  which  multiple  Industry  participants  may  bring 
models  to  a  single  federation.  The  type  of  data  exchanged  is  open,  but  the  actual  data 
exchanged  is  at  the  discretion  of  the  model  custodian.  Under  some  circumstances  it 
may  be  appropriate  that  true  performance  data  is  exchanged.  An  example  of  this 
might  be  where  models  from  a  single  company  are  joined  with  Commonwealth 
owned  models  in  order  to  make  some  assessment  of  system  performance  in  a 
realistic  threat  environment  in  die  context  of  an  acquisition.  Under  other 
circumstances,  models  from  a  number  of  Industry  sources  may  be  brought  together 
and  only  generic  data  is  exchanged. 

The  notable  feature  of  adopting  HLA  is  that  federate  custodians  determine  the  data 
exchanged.  In  addition,  any  data  internal  to  the  model  and  details  of  algorithms 
remain  encapsulated  within  the  simulation.  This  offers  a  degree  of  protection  to 
proprietry  data  and  algorithms. 
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As  the  technology  required  to  implement  the  Virtual  Ship  is  mastered,  the  emphasis 
of  the  program  will  be  directed  towards  development  of  methodologies  for  using  the 
Virtual  Ship  to  support  decision  making.  In  the  context  of  the  acquisition  process 
these  win  be  critical  and  it  is  essential  that  the  methodologies  pursued  facilitate  a  fan- 
assessment  of  competing  solutions.  To  establish  an  appreciation  of  this  characteristic. 
Industry  must  be  engaged  in  development,  and  exercising,  of  methodologies  for 
using  the  Virtual  Ship.  This  will  cover  not  only  the  mechanics  of  the  process,  but  also 
the  question  of  performance  measures  in  a  simulation  which  has  intrinsic  variability 
due  to  the  human  component  and  which  cannot  be  repeated  sufficiently  to  compile 
traditional  statistical  measures  of  effectiveness. 


9.  The  Way  Forward 

The  Virtual  Ship  concept  has  the  potential  to  provide  a  new  and  significant  capability 
to  support  maritime  platform  ownership  throughout  the  whole  lifecycle.  There  are  a 
number  of  particular  characteristics  that  underlie  this  potential.  The  ability  to  create  a 
realistic  virtual  environment  within  which  to  immerse  human  operators  will  enable 
the  complex  interactions  that  define  the  command  and  control  of  a  maritime 
platform  to  be  investigated  and  appreciated.  The  ability  to  integrate  virtual 
representations  of  current  and  emerging  systems  will  enhance  decision-makers 
xmderstanding  of  their  problem  domain.  This  aspect  is  equally  applicable  to 
capability  development,  acquisition,  tactical  development  and  mission  rehearsal.  In 
the  particular  case  of  acquisition,  the  use  of  a  Virtual  Ship  to  exercise  proposed 
solutions  to  requirements  has  the  potential  to  reduce  the  risk,  particularly  associated 
with  system  integration.  It  also  has  the  potential  to  reduce  the  time  required  to 
acquire  and  effectively  employ  new  platforms. 

The  development  of  a  Virtual  Ship  capability  will  demand  new  thinking  concerning 
the  way  in  which  such  a  capability  is  exploited  to  facilitate  mUitary  decision  making. 
A  particular  aspect  will  be  the  relationship  between  the  Virtual  Ship  and  the 
traditional  methods  of  operations  research.  The  rigorous  statistical  techniques  of 
operations  research  are  not  appropriate  in  an  enviroiunent  where  there  is  significant 
variation  due  to  human  performance  and  in  which  few  replications  of  scenarios  are 
available.  The  solution  may  be  to  use  operations  research  techniques  to  reduce  the 
number  of  scenarios  that  need  be  investigated  in  high  fidelity  representations  of  the 
Virtual  Ship.  Alternatively,  approaches  suggested  through  exercising  the  Virtual 
Ship  might  form  the  subject  of  detailed  operations  research  studies. 

There  are  a  number  of  threads  of  activity  that  will  bring  the  Virtual  Ship  vision  to 
fniition.  The  Virtual  Ship  Architecture  Working  Group  (VSAWG)  has  been 
established  to  develop  and  evolve  the  Virtual  Ship  Architecture.  Although  the 
activities  of  the  VSAWG  -will  address  each  of  the  elements  of  the  VSA,  the  principal 
focus  wiU  be  upon  determination  of  the  standard  for  data  exchange  amongst  models, 
otherwise  known  as  the  VS-FOM.  A  parallel  thread  of  acti-vity  will  seek  to 
demonstrate  use  of  this  data  standard  through  the  conduct  of  technical 
demonstrations.  It  is  anticipated  that  the  outcomes  of  these  demonstrations  will 
feedback  to  evolve  the  data  exchange  standard. 
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Industry  will  be  engaged  in  the  process  of  determining  the  VSA  through  an 
invitation  to  participate  in  the  VSAWG.  In  addition.  Industry  will  be  invited  to 
participate  in  technical  demonstrations.  This  will  allow  the  Industry  perspective  to 
be  incorporated  within  the  VSA.  Industry  will  acquire  the  intimate  knowledge  of  the 
VSA  required  to  engineer  models  in  accordance  with  it.  They  will  also  establish  a 
core  of  expertise  in  the  High  Level  Architecture. 

As  the  VS-FOM  becomes  stable  it  will  form  the  backbone  through  which  models  may 
be  brought  together  in  order  to  simulate  aspects  of  warship  operations.  It  will  be 
appropriate  to  review  legacy  models  within  DSTO  and  re-engineer  them  to 
compliance  with  the  VSA.  Indeed,  a  critical  contribution  that  DSTO  wiU  make  to  the 
Virtual  Ship  is  the  ability  to  represent  the  threat  environment.  Models  that  contribute 
to  this  will  be  brought  to  compliance  with  the  VSA  as  a  matter  of  priority.  It  -will  be 
appropriate  to  review  research  programs  in  order  to  identify  those  aspects  that  might 
profitably  be  used  as  a  basis  for  VSA  comphant  models.  It  is  anticipated  that  parallel 
activity  will  occur  in  Industry,  so  that  they  may  demonstrate  and  exercise  the 
capability  of  their  systems  in  the  Virtual  Ship  environment. 

During  this  review  process  the  data  required  for  models  will  be  considered  and 
common  requirements  identified.  This  will  provide  the  impetus  for  development  of 
data  standards  across  applications.  Alternatively,  a  requirement  may  be  identified 
for  tools  that  transform  common  data  amongst  a  variety  of  related  formats.  It  is 
through  identification  of  common  data  requirements  that  the  Virtual  Ship  wiU  be 
able  to  provide  support  to  a  platform  from  the  earliest  stages.  The  availability  of  data 
in  common  formats  will  facilitate  application  of  modelling  and  simulation  prior  to 
the  platform  existing. 

As  a  suite  of  models  compliant  with  the  VSA  is  developed,  methodologies  for 
managing  them  will  be  developed,  as  will  methodologies  for  effectively  integrating 
them  in  support  of  specific  applications.  Guidelines  wiU  be  developed  for  exploiting 
the  Virtual  Ship  in  support  of  decision  making,  whetiier  this  is  associated  with 
acquisition  or  operational  matters.  A  suite  of  tools  will  be  available  that  assist  in 
coi^guration  of  the  Virtual  Ship  and  in  data  compilation  and  analysis. 

An  essential  characterisitic  of  the  Virtual  Ship  is  its  human-in-the-loop  capability. 
The  guidelines  for  its  use  will  emphasise  capturing  the  performance  of  trained  RAN 
operators  in  a  manner  that  is  credible  in  the  eyes  of  Virtual  Ship  users  and  the 
decision  makers  who  utilise  its  outputs.  The  contribution  of  the  RAN  to  this  process 
is  critical. 

The  Virtual  Ship  will  evolve  into  a  dedicated  facility  available  to  support  activities 
across  the  whole  of  the  Defence  Department.  It  will  contribute  significantly  to  force 
development,  acquisition,  training,  mission  rehearsal  and  tactical  development. 
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11.  List  of  Acronyms 


AAR 

After  Action  Review 

ADF 

Australian  Defence  Force 

ALSP 

Aggregate  Level  Simulation  Protocol 

API 

Application  Programmers  Interface 

ASST  ASS 

Australian  Surface  Ship  Towed  Array  Sonar  System 

ASW 

Anti-Submarine  Warfare 

O 

Command  and  Control 

GDI 

Common  Data  Infrastructure 

CMMS 

Conceptual  Models  of  the  Mission  Space 

COTS 

Commercial  Off  The  Shelf 

DERA 

Defence  Evaluation  and  Research  Agency 

DIS 

Distributed  Interactive  Simulation 

DMSO 

Defense  Modelling  and  Simulation  Office 

DSTO 

Defence  Science  and  Technology  Organisation 

ESSM 

Evolved  Sea  Sparrow  Missile 

FED 

Federation  Execution  Data 

FFGUP 

FFG  Upgrade  Project 

FOM 

Federation  Object  Model 

FY 

Financial  Year 

HLA 

High  Level  Architecture 

IPR 

Intellectual  Property  Rights 

IPT 

Integrated  Product  Team 

IRST 

Infrared  Search  and  Track 

JCSE 

Joint  Command  Support  Envirorunent 

LAN 

Local  Area  Network 

LFAPS 

Low  Frequency  Active/ Passive  Sonars 

LOS 

Line  Of  Sight 

MEL 

Master  Environment  Library 

MPD 

Maritime  Platforms  Division 

NATO 

North  Atlantic  Treaty  Organisation 

OMT 

Object  Model  Template 

OR 

Operations  Research 

OT&E 

Operational  Test  and  Evaluation 

PC 

Personal  Computer 

PDU 

Protocol  Data  Unit 

RAN 

Royal  Australian  Navy 

RTI 

Run  Time  Infrastructure 

SBA 

Simulation  Based  Acquisition 
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SEDRIS  Synthetic  Environment  Data  Representation  and  Interchange 
Specification 

SMU  Seahawk  Midlife  Upgrade 

SOM  Simulation  Object  Model 

STOW  Synthetic  Theatre  Of  War 

UHF  Ultra  High  Frequency 

UK  United  Kingdom 

US  United  States  of  America 

VSA  Virtual  Ship  Architecture 

VSAWG  Virtual  Ship  Architecture  Working  Group 

VS-FOM  Virtual  Ship  Federation  Object  Model 

WIP  Warfighting  Improvement  Program 
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